I described in Different Settings for Development and Adhoc Builds in RubyMotion how I set up my Rakefile to have an
env variable that represents whether the current build is for
env var helps so we can modify the configuration slightly (namely app.entitlements) accordingly.
In the app, we can't know if we are running an ad hoc build via something built-in or by accessing this
env variable. We can't use RUBYMOTION_ENV since it has only these 3 possible values –
release. (It is
development for ad hoc builds). I have resorted to this workaround:
1. I already have a module for each app, so I add these methods in there:
module MyApp def self.app_store? RUBYMOTION_ENV == 'release' end #Definition is overridden via adhoc.rb for ad hoc builds def self.adhoc? false end def self.app_store_or_adhoc? app_store? || adhoc? end
2. Create a file called adhoc.rb:
#Sole responsibility of this file is to override MyApp.adhoc? to return true. #Add this file to the end of app.files if and only if it's an ad hoc build module MyApp module_function def self.adhoc? true end end
adhoc.rb is at the root of the project, i.e. outside app/ so it isn't automatically included when building the project.
3. Add this into Rakefile so adhoc.rb is included:
Motion::Project::App.setup do |app| if env == 'dev' #... elsif env == 'adhoc' #... app.files << "./adhoc.rb" elsif env == 'appstore' #... end end
4. In your app, you can now have a different code path for ad hoc builds:
if MyApp.adhoc? #... else #... end
if MyApp.app_store_or_adhoc? #... else #... end
I'm not sure if compilation order could cause a problem, but maybe updating app.files_dependencies will help with that. But given the way it's structured, any issue with loading order should be exposed during ad hoc testing and not affect app store distributions.