I have an app on AppStore that I would like to improve with StoryBoard. I was recomended to build a new app from scratch instead of trying to add storyboard to an old app. So I have done that and now I would like to upload it to the AppStore and replace the old one.
I understand that the bundle identifier and app name must be the same. Do I have to make sure any other stuff is the same?
Yes, you can do this no problem.
Just make sure to use the same App bundle identifier i.e. com.companyname.appname as in your original app.
Then use the same distribution license that you would normally use.
You have to release the new app as an update to the old app but apart from that you can change anything else.
You also have to make the new version number greater than the current apps version number.
To the users it will look like a normal update but in the background you will have essentially replaced the entire app.
You could consider this as an update of you app.
Bundle version should be higher then before (for example 1.1 or 2.0 if the previous one is 1.0) - this usually depends on how big the difference will seem to the users.
And also: if you are saving anything to documents folder make sure that the new version is compatible with the old data.
New version should be able to run on device:
if there was (any) previous version installed
if there was no previous installation of your app
Related
I have a Universal iOS app that has been in the App Store for two years now. I am working on a massive update for it. I have learned a lot since then and I feel that the best thing for me to do is to rewrite the app from the ground up. I can just strip out the app but I would rather start from scratch with a new Xcode project and submit it as an update.
However, I'm not sure if this will work. What do I need to change in the plist and other settings so that this new project will be recognized as an update to the existing one? Is it even possible?
You should just be able to use the App ID/Provisioning profile of the existing app when you develop the new one.
In XCode, you'd set the Bundle ID to whatever the app's identifier is, and update CFBundleVersion and CFBundleShortVersionString to reflect the current version of the app.
Keep in mind that you can't add to the required device capabilities (meaning make it more restrictive), so it has to match what they were for the old version.
My client wants to update his iphone app but he doesn't have access to the source code. Is it possible to update the already existing app by building it from scratch?
Yep, you just need to use the same bundle ID in your app and maintain the versioning (just make it higher than what it is in the app store). So long as you have the developer account that published the app, then you will be fine
Your client can update the existing app if he has the access to the store. Else, while building the new application, he has to maintain the package identifier with higher app version and the rest will be no problem as far as the practice is going on.
I have a question regarding App Store published apps. I'm about to submit an iOS app and I wonder if, when submitting future app updates, it is possible to force the previous version to be uninstalled before installing the update? How are updates managed?
Thanks!
You need to submit the app update as an update to the existing app, not as a new app. There is no need to uninstall the old app. The update will replace it.
Make sure the update is backwards compatible. More specifically: preserve the user settings and any other piece of data your app stores locally.
If you really need to submit a new app to replace the old one for some reason, you can use a custom URL (documented here) to force the user to use the new app.
You will need to make two changes:
In the new app: register the custom URL.
In the old app: launch the new app by invoking the custom URL as described here
I find that you are worried about sqlite database changes.You can change the name of the sqlite file in new version project.
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.
For reasons too convoluted to get into, I had to switch to a completely new project to update an app in the App Store.
Is there anyway to get access to the sandbox of the old app or will the new one just create a completely separate sandbox? In testing my dev builds of the old and new app they are completely different document directories so my archived info doesn't survive the update.
Does going through the app store effect this in any way or am I just out of luck?
I've matched Bundle ID's and provisioning profiles and that hasn't helped anything.
If you are submitting the completely new version as an update, the data in the NSDocumentsDirectory and NSLibraryDirectory will be preserved. If you are creating a new app in iTunes Connect, the data will not be available and there's no way of getting it back (because you can´t access the sandbox of other apps).
To test this, the best thing you can do is to install the old version of the app on your device and run the new one to update it. If you matched the bundle id correctly, instead of creating a new app on the springboard it should update the existing one. Data should be preserved in this update.
Remember to set your version number to something higher than before. For example, if your old app is version 1.0 you should try with 1.1 or 2.0.