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 dev/adhoc/appstore. This 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 – test/development/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

Or:

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.