I have an app on the Store for which we’re readying an update.
The other members of our team have the App Store version already loaded up (~purchased) on their respective iPhones -- and those contain User Data which each member needs to be able to keep.
In the meantime, we need to test out a Beta version of the next version of the app.
Presumably, we’d need to have the two versions (ad hoc, and app store) co-existing on each device, at least until everyone’s signed off on the beta and it’s uploaded to the store (at which point, they'd delete the beta version).
[Once it’s on the Store, of course, they can each update their main (i.e., Release) version of the app via the usual App Store 'update' mechanism. In that case, all their user data is still retained intact.]
So assuming that’s the proper workflow ...
How do I issue a Beta to the team, and have it not replace/overwrite the existing App Store version?
I’ve tried customizing parameters in the beta’s “[appname]-Info.plist”, but haven’t found a setting yet that allows the two versions (beta and release) to co-exist on the same device.
Any ideas? And is this is the proper approach to them being able to keep their data?
(And last, how might I do it with & without a script? I assume there's just one parameter that'd need to be changed.)
I hope this all makes sense -- thank you in advance for your help!
So you want to have two versions of the same application on one device? I don't think there's a way to get this effect -- updating an application, which keys on unique CFBundleIdentifier, replaces old version bundle but not data.
For the effect you want, you must have two distinct applications. They need different CFBundleIdentifiers, so they won't overwrite each other. They then cannot share data, so you'll have to arrange for export/import involving an off-device shared space.
If you don't want this hassle, issue the team extra devices and test on those. The team's primary devices remain on the AppStore version. You must still export/import to bring content from the test devices to the primary devices. Any paid content each has on the App Store version should be available for their beta, though, as usual for app upgrades and one-owner multiple-devices scenarios.
Related
I have an app that has been released on the app store with separate versions for iPhone and iPad. Now I wish to convert the app to a Universal version but I have an issue which I'm not sure can be resolved.
Both versions of the app use a different bundle identifier (for example com.mycompany.app.iphone and com.mycompany.app.ipad). I want the new (universal) version to overwrite either of the old versions when downloaded from the app store. To complicate matters further, core data stored for that app needs to be retained.
I'm not sure its possible and perhaps the protocol is to release the universal version under a new bundle identifier and have users start again but if a workaround is available it would be really helpful.
your options:
1: Update both your iPhone and iPad apps with this universal binary (with respective bundleIDs and app names)
2: Create a way to sync data between apps by creating a web service. one of the apps I have used extensively - Gas Cubby, does this for transferring data from its free app to paid app. You could implement it in a similar way
3: Nuke one of the apps, update the other app with the universal binary
Option 1 is the easiest. 2 will take longer. 3 is dirty.
(will update this answer with more options if I come across any)
As far as I know and from what I've read before, you can't change the bundle identifier of an app published in the app store.
Due to the sandboxing, accessing the data of your old app from the new app is also impossible.
There are several ways you could go about solving this issue, depending on which one suits you best. You could create a new universal app, and abandon the old ones hoping that the users change their preferences, or you could be pushing the same update to both applications, essentially, having the identical app under two different names. I'm not sure what are Apple's stances on the second option, but it will be a hassle either way. Good luck!
I am planning to release version 1.0 of my app now. I plan to release 1.1 in the next 2-3 months.
What are the things I need to take care of now for the initial release?
Also what should I select as SKU Number and Bundle ID in iTunes Connect for submitting 1.0?
Version numbers in software are completely arbitrary. Usually, you have a major version and a minor version. Consider the version "1.2". It's version one of the software and there have been two minor updates since the original release. (Note that this is subjective because it could technically be version 3 - where each release is a version change.)
You should not release a second version just for the sake of pushing an update. Generally, an update contains a bug fix or a feature enhancement. (For example, I made a game called "Nippon". I'm updating it to have a new user interface on the iPad as well as fixing bugs. In contrast to this, consider another update I made to another app, which I just changed the icon. See the difference?)
As far as when to release your app, that is totally up to you. You don't need all of the features right away, but make sure that those that you do put out are completely implemented. Don't rush to put out something with features that are incomplete. Users will hate you for it. Instead, choose a core group of features that are your app. Make those work really well and then work on other things for the next version.
Here's a related excerpt from the Apple Developer Resources "submission tips" section (requires login):
The two most common reasons for application rejection are issues with core functionality and crashing. Core functionality encompasses the belief that customers rightfully expect all the features described in the marketing text and release notes to work as described, and likewise that all the buttons and menu items within the application will be fully functional (i.e., no grayed out buttons or notifications that a feature will be implemented later). Before you submit your app for approval, make sure that every aspect of your application is fully functional and that the marketing text and release notes correspond to the end user experience.
Also, make sure you thoroughly test your application on iPhone and iPod touch in addition to the iPhone Simulator. A large percentage of applications are rejected due to various types of crashes, including crashes on launch, which would have been found and dealt with if they'd been tested on an actual device. Don't skip that step in the development process.
Make sure that your app works and works as advertised. That should be your goal for version 1.
As far as SKU and bundle ID:
SKU is supposed to be a four letter code, representing your app. In the old iTunes connect, you would see your SKU represent your downloads. I just checked and it seems that they print out the entire name of your app. However, just to illustrate, a valid SKU for Nippon would be NPPN. (I actually use that one.)
Your Bundle ID should be a reversed domain name. For example, com.mosheberman.myapp could be a bundle ID for my app. You don't have to actually own the domain name, by the way. For Nippon, I used com.yetanotheriphoneapp.nippon.
Hope this helps.
I have an application already on the store and would like to release an update. Since my app deals with databases and I've had to change some parts of it, I would like to ensure that the update does not affect the existing functionality in any way once the user updates from the App Store.
What I did was this - install the first version of my app on my device. Changed the update's version in info.plist to 1.1 and run it via xcode (and install on my device). But what happens by doing this is some of the changes I made to the XIBs do not show up. It looks as if the app was only half-updated (if you know what I mean)
Is there any way to update an existing app programmatically without having to go through the app store and then find out it could lead to a disaster?!
Thanks for any help!
I would double check your build configuration. Between building the two versions of the app, I would recommend a "Clean All" just to be safe. The process you described works to verify updates. The only other alternative I can come up with is to create Ad-hoc distributions of both versions of your app, and install those.
I am near the end stages of developing an iPhone application and will be releasing it as both a 'lite' (ad-supported) version and a 'pro' (ad-free, likely with additional functionality at some point) version.
I've followed suggestions here and elsewhere about creating multiple targets, etc. and am able to build these without any problems.
But this does bring to mind a question: What is the best, most user-friendly, accepted way in which to handle transitioning from a lite version of an app to a pro version?
As I see it - and please correct me if any of my assumptions are wrong - there are potentially two ways to do this:
Give each application its own Bundle identifier (ie. com.companyname.fooapplite and com.companyname.fooapppro). This will result in both being treated as being completely separate entities. Data is not automatically migrated should a user move from one to the other and both could very well have both installed on the same iPhone at the same time.
Give each application the same Bundle identifier (ie. com.companyname.fooapp), so that they are treated as essentially the same application. The lite version of the application will be overwritten by the pro version if they download and install it. Data from the lite version is maintained in the pro version.
The latter seems ideal to me - I can't imagine someone wanting to keep a lite version after they've just purchased a pro version - but this brings up a few questions:
Does Apple even allow option #2?
Will using option #2 result in any goofiness I should be aware of, ie. the two versions stepping on eachother in some way.
If it's not allowed, is there a suggested practice in place to migrate data from what are basically two completely different applications? I'm aware of StoreKit, but it isn't supported on free applications.
As it is, this current app doesn't really generate data of huge value and the worst thing that will happen is users will have to re-enter some authentication credentials upon upgrading to pro. But down the road, if I were to develop a similar app that stores valuable data locally, I'd like to know how to best transition users and their data in a seamless manner.
Thanks,
Jeff
One more option is to exchange data from the Lite to the Full version via a URL. Register a myFullApp URL with the full version and have the Lite app present an upgrade option that calls that URL with the various data you want to exchanged encoded in it.
That does require the user fire up your Lite version and hit a button, but it's fairly simple too.
I have not tried this myself, but a third option to exchange small amounts of data is to use the Keychain API. Apps that share an identifier stub -- com.companyname.foo as a parent to com.companyname.foo.fooapp and com.companyname.foo.fooapplite -- can supposedly write to the keychain from one app and read from the other. Haven't seen this done, but a lot of people claim it's possible. And in any case, the keychain is probably a good place to be storing things like authentication credentials.
Option four would be to have the lite app store some user data on a server you operate, and have the full app retrieve it from there, but there are all kinds of problems with that approach.
Those of us with iPhone apps (released or unreleased) are able to send out limited beta builds using ad-hoc distribution. While the Apple docs for this have a few holes in them, there are a number of blogs, postings and other articles out there on "the net" that fill the gaps.
However, one thing I haven't seen anyone mention, and I was curious about: When you do a beta build do you use the same app id as your released (or to-be-released) app?
The argument for using a different id is that the beta could then still run alongside the released app. This is probably more important if you already have a released version in the field.
An argument against is that the beta would not have access to any data the released app may have generated, and vice -versa. This may or may not be what you want on a case-by-case basis.
Are there any issues with this approach? I only have one app id registered currently, but IIRC there are no obstacles to just creating more as necessary..?
Would be interested to hear what others are doing.
We use the same app ID, just for simplicity. There are enough headaches in ad-hoc distribution that we don't want to confuse anybody with "why are there two apps on my phone?" problems.
I use both different Bundle Identifiers to allow my testing team to have multiple versions of the app installed as well as different Bundle Display NAmes, so they can easily see that they are using a development or beta build and report that number back to me when issues are found.
I think it depends on how important the data in your app is. If the data is valuable I don't think beta testers would want it putting at risk, hence having a separate AppID would make sense. Of course, that also means that they won't test the application as fully either and any "upgrade" code won't get tested.
In my case (Yummy), the data is just a cache of delicious.com so a catastrophic bug in my code would mean, at worse, downloading all your bookmarks again. So I tend to use the same AppID for everything.