A week ago I have submitted an application which supports Blackberry Z10. Yesterday, I finished another version which supports Blackberry Q10 and Blackberry Q5. At the moment, my app on the market is version 3.0 and it only supports Z10.
If I upload a new bundle, the version of the app automatically increase to 4.0. This bundle also only supports Q10 and Q5 as the previous version already supported Z10. In this case, what will happen to Z10 users? Will they receive the update version (4.0), as it is a newer version, although I already set the specific devices to Q10 and Q5?
In the future, if I make some update, how can I manage it?
Cheers,
Disclaimer: I don't develop for BlackBerry 10, but I do for legacy BlackBerry OS versions, and I believe this works the same within the BlackBerry vendor portal (see comment by Peter Strange below confiming).
If I upload a new bundle, the version of the app automatically increase to 4.0.
First of all, this is what the web interface does by default. It auto-increments the major version number (the number to the left of the decimal point). However, the field for version number is editable, so if you don't like the default choice, you can change it. For example, if you would like the new version to be 3.1, or 3.0.1, instead of 4.0, then you can change it manually. Personally, I don't think you should increase major version numbers simply to add a new device, within the same line of OS's.
This bundle also only supports Q10 and Q5 as the previous version already supported Z10. In this case, what will happen to Z10 users?
Z10 users should see no change. If you previously have a version available for Z10, it should still continue to be available. Whenever you upload a new bundle, you should use the web interface to specify which devices that release bundle supports
(alternatively, you can make a zip container of bundles, and use release.xml/devices.txt to specify device support).
So, if the new release only specifies Q10/5 support, that bundle won't be served to Z10 users. Z10 users will still have access to version 3.0.
In the future, if I make some update, how can I manage it?
I would recommend that you only change major version numbers when the functionality of your app significantly changes. Version 3.0 to 4.0 should be a major change, visible to the users. I personally, then use minor version numbers for small changes, that are also visible to users. For example, version 3.0 to 3.1. Finally, the last digit of a version number I reserve for small changes, such as a bug fix that doesn't add new features, but prevents a problem. For example, version 3.0 to 3.0.1.
For a new release that only adds support for a new device, I would probably just change the last digit (e.g. 3.0 to 3.0.1). But, that's your decision.
If you have a new release that only adds support for new devices, then you should be able to only upload a new bundle that specifies support for those new devices, rather than uploading new code for all devices. This way, a Z10 user isn't bothered to install an update when the newest release actually contains nothing new for their device.
Related
Is it possible to maintain 2 application versions of the same application at the same time?
When a device gets too old and won't receive any updates from apple, you will stay stuck on the last version supported by your device. When downloading apps from the app store that require a higher version of iOS, it will automatically download the last compatible version from the app store. this is default behavior as stated: https://apple.stackexchange.com/questions/160089/how-does-ios-appstore-handle-multiple-version-targeting-different-version-of-ios/336985#336985
While we will mostly update our latest version, can we still update the 'legacy' versions of the app for older devices? can we still add features to the old versions (eg iOS <11) while adding the same features in our new app?
You can maintain two apps simply by giving them two different bundle ids.
But you probably cannot update the "old" app without recompiling it against the current iOS or prevent a modern user from seeing and downloading the "old" app.
To give an example, if your old app was 32 bit only, a 64 bit user cannot download it. But if you update it, you have to make it 64 bit.
We have a browser application and this application is using by different clients. Each client is using separate database and service. Regularly(quarterly) we are releasing the upgrade with enhanced features. But some of the clients may not upgrade to the latest. So different clients are using different versions of our product. There is no issue with this because each clients are using their own Database and service. Recently we build up a iOS app for the same application. In app store we can upload only the latest version of our app, how the clients in lower version can install respective version of their app? Latest version app may not work with lower version of service and Database
Different clients needs to install different versions of same app from app store.
In App Store Connect (where you manage your apps in the App Store), you can choose which versions you want to remain in the App Store after you release a new version. The purpose of this is to allow an older version to be downloaded in case the user have an older device or iOS version that don't support the new app version. - So I guess this feature is not really helping in your case.
I would suggest you make the same version for everyone, and then within the App (I assume your clients have a login) based on their user selects what you want to present them. - Connecting to their old database and deactivating the new features as an example. This will also give you the opportunity to showcase that there is new features which they may want to opt-in on.
You can release a completely new app for each version. Ex. YourApp 1.0, YourApp 2.0 (This is not uncommon, but it's usually more if the same app is radically changed/improved, and you want the old version to remain for some time until you retire it completely).
Hope this clarifies a bit :)
I wonder if there is any way to distribute different versions of same app (same means same bundle id, same account) in Apple Appstore.
Lets say, I want to distribute, MyApp (com.stackoverflow.myapp) version v1.2 but there is already a version v1.1 open to public. Is it possible to keep both version open for public. And fixing issues and release different sub version like, v1.1.2 and v1.2.2.
As far as I know with single bundle its not possible. But still I am curious if there is any workaround.
When you release a new version on to the app store, you can now select an option for a "phased release", where the update is shown to current users incrementally over a 7 day period, but at the end of that seven day period the updated version is available to everyone. Also, new users will get the latest release when they install from the App Store.
You cannot maintain two "active" releases on the store.
If you want to test a new version or new features with a limited set of users then TestFlight may be an appropriate tool.
You can use whatever versioning system you want (such as semantic versioning), but you can't distribute multiple versions of an app at a time without uploading them to the App Store as 2 entirely different apps
When submitting an update to an app to the app store (via iTunes Connect?), is the update necessarily a whole binary? Can an update come in the form of a patch? If a second version of an app shares a lot of assets and logic from the previous version, does all that logic/resources get reinstalled wholly regardless?
There are no patches. It's installed as an entire read-only bundle. The old bundle is replaced with the new bundle.
Application data is retained (ie. documents folder, NSUserDefaults).
As everyone said before me Apple does not supply a way to hot-patch native apps, moreover it has a clear restriction - "No remote code injection".
The only thing I can add is that hybrid apps which use a javascript platform allow you to remotely replace the JS file, so you can actually change functionality remotely.(without having to release a new version) other solutions I have seen are in the gray area and allow you to run Lua Script remotely to change app functionality.
We # Rollout.io have a different approach, we allow you to hot-patch production apps without code injection on native applications, you can read more on how the tech works here
Rollout is meant to help mobile developers solve production quality issues, hot-patching production apps, debugging production env, adding/removing analytics, etc.
Disclosure: I'm from the Rollout.io team.
iOS 6 now supports delta app updates. This is awesome, and makes Real Racing 3 (a 1.1GB app) update in about 30 seconds instead of 20 minutes!
https://developer.apple.com/library/ios/#qa/qa1779/_index.html
Q: How can I reduce the downloaded size of my app update for users
that already have the previous version installed?
A: Starting with iOS 6, the app store will automatically produce an
update package for all new versions of apps submitted to the store.
This package is optimized for updating an app from one version to
another, and contains files that have changed between the prior
version of an app and the new version of the app, excluding files that
have not changed.
When used optimally, an update package is significantly smaller to
download than the full package of the app and the update will install
more quickly. Also, in many cases, this mechanism allows updates to
large apps to be downloadable over cellular networks where app
downloads are subject to a size limit.
In addition to new content, the update package contains instructions
on how to transform the prior version of the app into the new version
of the app. New files will be added, modified files will be replaced
with their updated counterpart, and deleted files will be removed as
part of this transformation. As far as the developer and user are
concerned, this process is entirely transparent and the resulting
updated app will be indistinguishable from a full download of the
corresponding updated version of their app.
Further instructions for developers available at the link above.
I've got an application (not free) on the Appstore, it was one of my first app. I'd like to update it with a lot of new stuff, graphics etc. Most of these new feature such as collection views are available only from iOS 6, the app targets iOSes >=3.1. I prefer to not mess around with runtime checking.
Since is a paid application I'd like at least that all people with iOS6 could upgrade it for free, and I don't want to screw older versions.
What happens if I submit an upgrade that target only iOS=>6, would older iOSes be notified about the upgrade? could they do the upgrade? will be shown something such as "The upgrade will be available only for iOS>=6"? or it will be notified only with matching devices?
I've read that question (little bit old) and there is a Use Case not clear to me here
Thanks,
Andrea