In order to change the bundle ID of an app in App Store Connect, there cannot be any previously-uploaded builds; if there are, the bundle ID cannot be edited. Therefore, to change the bundle ID (and subsequently remove an app's build history from App Store Connect), would one have to remove the app from App Store Connect and reclaim it? When an app is removed this way, the app's name is released to other developers, but is that immediate? And would anything prevent me from creating a new app with the same name right after I removed it from App Store Connect? The app is still in the prepare-for-submission phase.
I've gone through this process to hand an app over to another developer - we didn't care about losing the build history, so this is faster than transferring it.
would one have to remove the app from App Store Connect and reclaim
it?
I believe that is the case, although you probably could rename the original rather than deleting it.
When an app is removed this way, the app's name is released to other
developers, but is that immediate? And would anything prevent me from creating a new app with the same name right after I removed it from App Store Connect?
In my case, the other developer was able to use the name within an hour. Nothing should prevent you from re-using the name, as long as no other developer grabs it before you do.
In your case, I would try to register the name with the new bundle ID right away, and just re-try ever couple of minutes until you get it back. I wouldn't be surprised if it takes a little time to get all of Apple's systems updated.
Please let us know the result!
Nothing from Apple explicitly said I couldn't do this but developer support said there is no guarantee it'll work, and not just because another developer may quickly take it, but for "a lot of other reasons" (according to support); the system was designed against this kind of behavior, I was more or less told. TLDR: not trying it. 😏
Related
I have an iPhone app that now needs to be removed. I can do this by following the steps in iTunes connect:
Untick all territories in pricing and availability
Then in Additional Information : Delete App
I have completed step 1 and am about to follow step 2 but I have a question that I cannot find answered on any of their help/docs nor online elsewhere. Once I delete the app - it will get removed from the app store, but will it still stay on all users iPhones that have already got the app downloaded and installed on their phone? Or will it automatically be deleted/removed from all phones?
Ideally I need to remove the app completely so that it can no longer be used be new or existing users even if they already have it on their phone.
It will stay on the user's phones.
In your case even worse for you: If they backed up/synchronized the application LOCALLY via iTunes, they got a local .ipa-file (an instance of your app), which they could even restore, after they setup the device once again.
For the users this is a pretty convenient way. So, if you want to delete your application. Inform users about that step and if you have a good exit strategy, users will adopt this and will delete it on their own.
The app will stay on the users IPhones. There is no way to remove it remotely.
The only thing you could do would be to release new version with a lock but then you will probably get trouble with Apple.
Before Swift 2.2 the UUID value was the same every time I opened the app, now changes at every opening
I use this code:
UIDevice.currentDevice().identifierForVendor!.UUIDString
How can I do now to identify the user?
Every time you delete the app, the UUID may change.
If you just close and open the app, it's should be the same.
But if you delete the app (or install it again via xcode), it might change.
There are a couple of answers that explain why the UUID is resetting. There's one that offers a potential work around, but I'd consider it far from ideal. But I want to highlight something important about the way UUID's work that serves as a great workaround that has absolutely zero impact on the production OR debug version of your code base or compiled binary.
The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them.
All you have to do to prevent this value from changing while developing App-A is to simply install App-B from the same vendor (yourself) and keep it installed during the life time of App-A's development. This is literally as simple as starting a blank new iOS project and install the blank slate to your test device (using the same developer account & such), and then never uninstall it again during development.
App-B keeps a constant UUID for the vendor (yourself) so no matter how many times you delete and reinstall App-A, it will always keep the same UUID.
This actually seems to be a bug IMO. Everytime I run my app in the simulator it generates a new Vendor ID. You can probably get round it by storing the ID into NSUserDefaults on the first bootup then retrieving / comparing the value from NSUserDefaults instead of getting it from identifierForVendor. This will save a static vendor id in defaults but in theory the vendor id will still be changing every boot up.
Kind Regards,
Krivvenz.
Update: I can confirm I have installed multiple apps on the same simulator too but the vendor ID is still changing on every boot.
Update 2: - I have logged this as a bug with Apple - 26195931.
The value of this property is the same for apps that come from the
same vendor running on the same device. A different value is returned
for apps on the same device that come from different vendors, and for
apps on different devices regardless of vendor.
The value in this property remains the same while the app (or another
app from the same vendor) is installed on the iOS device. The value
changes when the user deletes all of that vendor’s apps from the
device and subsequently reinstalls one or more of them. The value can
also change when installing test builds using Xcode or when installing
an app on a device using ad-hoc distribution. Therefore, if your app
stores the value of this property anywhere, you should gracefully
handle situations where the identifier changes.
Refer this link for more info.
I have an app live on app store. Due to some reasons i am about to push new app on app store, and want to uninstall old app from new app. Is there any way to uninstall/delete an iOS app from user's iPhone.
This is not possible, due to iOS not allowing people access to the file system. The only thing you can do, with an itms-services:// link, is prompt the user to download an app available somewhere for ad-hoc delivery.
Just add the current bundle identifier to the new app and submit as an update. It doesn't matter if it's the same project or a new one. As long as bundle identifier stays the same it will count as update.
This won't technically uninstall the old app, but it will look like it did.
Just remember that scheduled notifications and persisted files will remain as they were, you will have to implement some clean up logic to get rid of them.
I want to dynamically update localization of my iOS application without submitting an app update on App Store.
I know that i can't modify main bundle of my app (that stores Localizable.strings) without submitting an update to App Store because it's read only.
But there is one thing i can try: my application can download another bundle (with updated Localizable.strings files) from some FTP server to Documents folder and get new localization from there.
So my question is:
Is it legal to download new app bundles from FTP servers and store them in Documents folder without submitting an App Store update?
By "Is it legal" i mean: wouldn't my application get rejected by iOS App Store?
This is not recommended and absolutely not supported. Please consider shipping localizations as part of an app update.
I don't think that your app will be rejected, because Apple will not be aware of what you are actually downloading. But this really sounds like a super overkill and a super bad solution. You could store your strings in a file or database on your server and load it when your app launch, and have some code to handle it in app.
Just do the exact same thing as every other developer in the world does and stop trying to be smarter than the system: push app updates when you update your app.
If you want to download your own special app using your own special app update mechanism to /Documents then expect at least:
users to post reviews thinking you're malware;
the application not to download half the time because the user hasn't given your app access permissions; and
the downloaded application not to launch because the user hasn't gone out of their way to give it Gatekeeper permissions.
Also make sure you've done a cost/benefit analysis on Apple somehow not spotting the Gatekeeper prompt when testing your application and somehow not spotting it later.
My client is planning to release an iOS app (call it A) on the App Store which only has value for a limited time (say, a few weeks). After that time, they want to release another, basically completely different app (call it B), with functionality that is related to app A, but much more general. B will be built from scratch and will reuse no code at all from A.
They want to release B as an update to A, so as to retain their user base. Technically this should be no problem: we can change name/icon/metadata, as long as we keep the Bundle ID the same. But will this be a problem with the review process? Could Apple decide that it would be confusing for the user to release a completely different app as an update to an existing one?
So a different way of putting my question would be: can we freely reuse a Bundle ID for a different app within the same account?
Does anyone have experience with this?
What you want to do is absolutely acceptable. I don't see any reason why Apple would reject your app.
I personally recently updated an app with a new icon and a new name.
Granted, I kept most of the features from the previous version, but I really don't see Apple rejecting an update based on "it's too different from the previous version". Also, you often see notes in updates saying "rewritten from scratch", so this is also perfectly valid.
Technically you can do this, and lack of code re-use is irrelevant.
I have written and submitted apps that have have had their codebase completely replaced over their lifetime.
I've also changed an app's icons and name, so all the component parts are definitely OK to do.
You cannot reuse a bundle ID. Your best option is to just update the app. The review process accounts for major changes like this, so it will most likely be a longer review time.