I'm developing an iPad app that will be distributed in-house using the Enterprise Program membership. However, "in-house" means distributed to various worldwide locations.
The app binary itself will be universal for all content, client locations worldwide. However, the content (an SQLite DB file) will vary between devices. One iPad in UK has the English content file for a product, whilst another in France has the French content for a different product loaded.
The plan is to send the different client locations their content so that they can connect their devices to iTunes, install (or update, important!) the app and then copy the SQLite DB file to the device.
Can we do this, and how will it work? What are the limitations?
Acceptable answers must include the following:
Confirmation and description on how the SQLite content file can be synced
Confirmation and description/resource on how the distribution will work
I've found one somewhat related question:
Distributing database updates to an iPhone application without downloading the whole database
Would it be ok to have the App start up in a "neutral" mode?
Show icons for the different content types (Language Flags perhaps), and when you touched one, it would download from your server the appropriate data pack.
If certain users are only allowed certain content, maybe you could send them an out-of-band URL or password that they enter to get their personal content.
That way the App distro is always identical, and your server manages the customization packs.
I've now completed the project and can confirm that this technique is perfectly valid. We are distributing the application and SQLite database file along with the content (image and video) to the clients, which by the way has to enter the Enterprise Program themselves. The clients install the application via iTunes in an ad-hoc-manner, and then copy the database file and content files to the iPad in the iTunes interface.
The distribution itself is very straightforward, since the application package we are sending the clients are signed and provisioned. They won't encounter any issues with installing and updating, all they need is the free iTunes account and our application related files.
Different client's iPads can have different content. Updating the content or database file is quick and easy. Updating the application is also easy, just remind the clients to delete the app before adding the new version to their iTunes Library.
Finally a tip; if you're getting an error in iTunes (which BTW don't make sense) about your Entitlements when installing the app - add an application icon.
Related
I have an iPhone app that I'm distributing to testers. I followed these instructions:
https://developer.apple.com/library/ios/#documentation/ToolsLanguages/Conceptual/YourFirstAppStoreSubmission/TestYourApponManyDevicesandiOSVersions/TestYourApponManyDevicesandiOSVersions.html
And they work except for one of my testers, who does not use iTunes to synchronize his apps. He has many apps already on his phone and doesn't want to synch to iTunes because it sounds like it will delete them. So...Is there any other way to get a testing app onto an iPhone besides synchronizing with iTunes?
Simply distribute it using OTA ("Over The Air" distribution).
When you Archive your application using Xcode (menu Product -> Archive, I hope that's what you do already to keep debugging symbols so that you can symbolicate crash logs when testers send some back to you!), once you click on "Distribute", select the "OTA Distribution" option and follow the steps.
Don't forget to check the "Distribute for Enterprise" checkbox in the appropriate step and fill the requested informations (Product Name, URL of the IPA when you will upload it on your server, etc).
Once your .ipa and the associated .plist is created, upload them both on a web server, and make a link to "itms-services://?action=download-manifest&url=<the_url_to_your_plist_file_here>".
When the users will open this link from their iPhone, it will prompt to install the application on their device directly, without the need to plug their device to any computer.
There are many tutorials on the net about this, simply google about iPhone OTA distribution.
I strongly recommend TestFlight. It's free and it's easy and they manage all that server side work.
Since your user is afraid of the iTunes Sync Process (for good reason), why not recommending him to use the iPhone Configuration Ultility.
That tool does not do a complete sync but only transmits the app you specified to.
It is free, easy to use and very reliable. Well, sometimes it has its hickups on Windoze systems but that seems to be a normal experience for users of that OS.
How could a full version of my iOS app access / copy the database / settings from the free version ?
I'm thinking of providing a free version of my app and I can't see how people then buying the full version could get access to the data from my free version ?
All apps are isolated on iOS. They are installed as different iOS system users. One user do not have permission to access another user's files. In the old times, one common approach to address this problem is to enable iTunes file sharing. And tell users to manually copy the files.
Your better bet is to use the freemium model to sell your app. Make the app free, and unlock extra features via in-app-purchase. This way, your files, documents, settings won't need transferring to the pro version. The app itself becomes pro after unlocking.
Here is the guide from Apple: https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html (though not very intuitive).
The walkthrough here: http://troybrant.net/blog/2010/01/in-app-purchases-a-full-walkthrough/ is very helpful.
Last but not least, be aware that in-app-purchase is crackable. So please read: How to detect "IAP crackers"? , Verifying In App Purchase Receipt from Client , and https://stackoverflow.com/questions/4715414/apple-in-app-purchase-verify-receipt , verify in app purchase , In App Purchase Receipt verification within app .
Note that you are supposed to setup a server to validate iap receipts. Though it's doable from within the app, it's not safe. As far as I can remember, you can test in-app-purchase through StoreKit in iOS simulator v5.0, that should be Xcode 4.2. Before that, it can only be tested on a device.
#Dominik Hadl mentioned you can use a server to sync the file. The operation is usually complicated. If you prefer this idea, you can choose to use custom url scheme to launch one app from another to ease the operation. See steps below:
User press "Begin sync" in the free app to upload the file to your server
Server return the ID of the file to the free app
User press "Launch Pro App and Download my file", which leads to a custom url scheme to launch your Pro version (must be installed first), with the file ID
Pro version use the file ID to download that file directly
I think the only way how you can do this is syncing the data with some server, registering the device and the syncing the data back to the full version.
Because all iOS apps are sandboxed, they can't access any other application data (unless you have jailbroken iOS).
Since multiple apps can share the same iCloud container, I'd say that the best practice nowadays is to "simply" store the data in iCloud.
(I'm putting "simply" under quotes, because it is easy to put data in iCloud and take it out; but if you actually want to do syncing, you may need to do more than just "I'll load from iCloud and save to iCloud" in order to provide the best experience to the user.)
We are currently developing an app for a client in the US, we are based in the UK. We need to "proof" the app as we make changes with our client i.e. get them to check the updates before we go any further.
The issue we're having is that transferring an IPA file to our client has been advised by their legal team as illegal. Is there any other way (simply) to allow our client to view this app regularly as we update it?
Cheers
IANAL, however, their legal team is wrong. When I click Build and Archive, and then Share by Email, the generated email file contains an ipa. This is an Apple-sanctioned method of doing ad-hoc sharing of iPhone apps.
What is probably confusing them is that if you're pirating apps, you use ipa files as well. However, saying that sharing ipa files is illegal is like saying sharing .exe files is illegal. Sometimes, yes. In this case: no, so long as the devices that are running it have been properly provisioned.
My company is looking to implement a large-scale In-App purchase model for an iPhone app.
Our biggest issue is that we don't want to go with a service like Urban Airship because it doesn't integrate well with our business model and the nature of the application itself.
So now we're looking to set up our own server to handle the In-App purchase communication as well as serving down the purchased content. We are not unlocking content that already exists in the app and will be downloading relatively large add-on content.
Are there any good resources for learning more about the server side component to this. I'm very familiar with how StoreKit works but the server side communication is an enigma to me.
Any help would be very much appreciated!
I implemented this by doing a simple plist + zip file download for purchasable content. The plist has a list of products available in it. There is a plist file for each version of the app, as in my case there are sometimes differences in content based on the version that the user has.
This scheme also supports versioning of individual content items, since sometimes you want to change one of the items in your store.
I do NOT follow Apple's guideline of purchase-then-download. I do download-purchase-unlock. I'm too nervous about someone purchasing the content, then having to wait for it to download. (My content files are pretty big).
Here's how it works:
App downloads .plist for itself. (MyApp_2.1.plist)
Opens up .plist, checks to see what version of each content item it has. Let's say the app currently has version 1 of content A, and version 5 of content B. The plist file above tells it that the current storefront should have version 1 of A, version 6 of B, and version 7 of C. So the app downloads content for B and C.
Content is stored in a zip file. In my case, these are game levels with XML files, audio, and graphical content. There is also a .plist with metadata for that game level, that includes the version number, and the AppStore ID for that item. The app unzips the content and then presents it in the storefront as a locked item. If the user has purchased it already, then they get the updated content automatically. If they purchase it, then I unlock the content at that time.
This is simple, can be done with any CMS (even a plain file-based web server), and supports multiple versions of content across multiple versions of your app.
If you want to see the UI, the app I did this for is a game called Lexitect, you can see how it all is put together from a UI perspective there. (It's free)
I've developed a generic iPhone app, intended for customization via a myapp.cfg file. I've successfully deployed the app to my adhoc testers via iTunes. My question is, how do I update their myapp.cfg file via iTunes. In other words, if they edit the .cfg file on their Windows PC or Macbook, how do they get it into the apps bundle in the iPhone?
You'll need to provide your own mechanism to download the config file into the application's Documents area; as app bundles are effectively sealed by the code signing process there's no way to modify the bundle post facto. As you have no interface to iTunes you need to provide your own mechanism - you might choose to do something like OmniFocus which uses Bonjour to discover the computer from which it retrieves its sync settings.
Looking at it another way; why use a config file at all? Other iPhone applications use a settings bundle and the standard application preferences as recommended by Apple, why do something different? There's always a chance that you'll confuse the user.