New Feature: iOS Container Apps in 9.0

Scripture App Builder started out supporting only Android apps. Publishing to Google Play requires you to comply with a small set of policies. Google will allow you to publish as many apps as you want as long as they abide by these policies.

Scripture App Builder started supporting publishing iOS apps with SAB 3.3 in 2017. However, Apple has a stricter set of guidelines for publishing than Google. The biggest hurdle to overcome is the Design requirement, 4.2 Minimum Functionality:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted. Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are simply a book or game guide should be submitted to the Apple Books Store.

We were able to add enough features that apps can be accepted and not reject for being “just a book” and recommended to the Apple Books Store. However, if too many apps are published from the same account, Apple starts rejecting all apps in that account under 4.3 Spam.

Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app …

In Scripture App Builder 9.0, there is a new feature for iOS Container Apps. In Scripture App Builder for Mac, on the IPA tab, there is a new section for App Type.

Prior to version 9.0, SAB would create an IPA file which was the iOS Template App with all of the assets (configuration, books, illustrations, icons, etc) included in a folder in the app. When the iOS app started, it would look in that folder for the configuration and start displaying the contents of the app. This is the Dedicated App which is still available. Starting with 9.0, you can now separate the template app from the assets. The user opens a Container app and select a language from a server. The server returns an Asset Package which is a zip file that contains all the assets (the ones that were written into a folder with the dedicated app).

Here are the steps required to implement an iOS Container App.

  1. Create a web application to host the asset packages. This web application will need to provide a page that is mobile friendly that will be used by the user to select the language and download the asset packages.
  2. Create an iOS project with App Type set to Container App. This app will not have any book collections but will have an iOS App icon and optionally the splash screen. If you use Firebase, you would put the Firebase configuration in the container app. The reported analytics will have the project name of the asset package.
  3. Build and publish asset packages. There is a new product in Scriptoria call iOS Asset Package that can publish the zip file to S3 Bucket. There is a Asset Packages S3 Bucket store that can be used by any organization. You do not need to make any changes to the project to build an asset package. In Scripture App Builder, you can customize the zip file name. If you don’t it will use the package name with a zip extension (e.g.

Future Work

  • We are working with Scripture Earth to create a Scripture Earth iOS app that will contain many of the languages that are currently linked to in Scripture Earth.
  • We are working to allow Scriptoria to notify Scripture Earth when new types of products are published and automatically link them.
  • We want to allow other organizations in Scriptoria to have this auto linking available to them.
  • We are looking into Scriptoria providing an API that can be used by your organization that will provide the data needed for a web page for selecting the language so that you don’t have to write a full web application.

Please contact me if you have questions or comments about this. We really would like your feedback!


This is really great, Chris, and something for us to think about on the literacy side as well. I was just talking to someone yesterday about the imbalance between members of the same language community falling into two groups. Language community members living in their home community in Mexico have almost exclusively Android phones and get their apps primarily by sideloading. But those who have migrated to the US for work very often obtain iPhones and have frequent access to WiFi and necessarily get their apps through the App Store. So while the dedicated approach works well for Android, a container approach seems like a great step for iOS.

And thanks for the vocabulary, I was using “universal app” for Duolingo/YouVersion like apps and “each language apps” for the SAB approach (until now). I like your vocabulary better.

Thanks again!