Release a country specific IPA/binary to iTunes connect - ios

I have a client that wants to release a new version of their app (new IPA) for a specific country, but keep the old IPA available for other countries for an undetermined amount of time. The app needs to have the same name, only users in this specific country will get the new version. Other countries will get the new one eventually.
Both IPA's currently have the same bundle ID, so the store listing/location will be the same.
Will Apple even allow this? I am trying to find documentation from Apple that states that multiple IPA's/binaries are not allowed for the same app. I don't even think you can select more than one binary when you upload to iTunes connect, if I remember correctly.
Note that making another target is not an option as the A) the codebases are separate and B) the client doesn't want to create another store listing.

You can not publish multiple versions at the same time, this includes regional segmentation. You can, however, limit availability of the app and leave only those regions that you want to keep supporting. This can be done at the Availability section at iTunes Connect:
https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ChangingAppStatus.html
Note that users from the removed regions will not be able to open the app's page in the App Store until you extend availability back. Not sure what happens on the devices with the app already installed, it will probably remain functional, but will not receive updates.

Related

iOS change Enterprise Account for existing App

I would like to know if its also possible to transfer an existing app from one Enterprise Developer Account. For example:
We already deployed an app with an existing account and specific app id: com.company.appname
Now i would like to transfer that app (app identifier) to another Enterprise account. Is that possible?
I already know how to migrate apps through developer accounts through iTunesConnect, but how does this work with enterprise apps? Is it allowed to create the "same" app identifier on 2 different accounts? What happens when ill update the app with all the data? The same identifier should only update the existing app, and not install a new one.
How does this work?
Edit: i´ve tried now something new:
use iExplorer to copy all Data from existing App to your Mac
install app with new identifier and new programm
copy all files back to new app, delete the "old" app.
Its about 10 Installations where i want to use the "new" development Programm. Maybe ill just copy all files manually, because in this case ill know that everything works fine.
Yes, you can migrate.
When you migrate your app to other enterprise account, then you will lost your app identifier from your account. When you will update the app from enterprise account, you will see an update of that application, not a new app. From your account, you won't be able to update or make a new app with the same identifier.
Please Note : This is screenshot from a developer account and i'm not sure about enterprise account portal. It should work like developer account too.
Yes, you can transfer your app from one account to another account.
You may not need to delete existing app from your account. There is an app transition process in apple developer account, which moves your app from your account to another account.
Answer to your question: When try to deploy it with another account again it says me "app identifier unavailable, already used" -
so any ideas how to solve this task with enterprise deployment? Or can
i migrate business apps to itunesConnect?
Recommended Solution:
You don't need to remove your app or bundle identifier from your account. You can convert business app into public app by updating certificates and provisioning profiles associated with your app. Then you can process for app transfer between two accounts.
Another Solution:
Delete your app from your developer account (along with bundle identifier) and then create a new app with same identifier in another account, to which you want an app tranfer
Here is an apple guideline for the same:
Transferring and Deleting Apps
You move apps out of your organization’s catalog of apps by
transferring an app to another organization or by deleting the app.
You want to transfer an app when you’ve sold the app to another
developer or you want to move it to another iTunes Connect
organization. You want to delete an app when you’re ready to retire an
app and there’s no chance you will want to offer it for sale or
download in the future or to reuse the app name.
You can transfer the ownership of an app to another developer without
removing the app from the store. The app retains its reviews and
ratings during and after the transfer, and users continue to have
access to future updates. There’s no limit to the number of apps you
can transfer, but each app needs to be transferred individually.
All transfers and deletions are performed by the team agent.
Transferring an App
You’ll need the team agent for the receiving organization to provide the team agent’s Apple ID and Team ID. Recipients can find their Team ID in their account at developer.apple.com.
The team agent is the only one who can transfer an app.
To initiate an app transfer
Make a record of app information you want to have after the transfer.
Because you won’t be able to view the app information after the transfer, make a catalog report (see Requesting Catalog Reports), note dates the app was available on the store (see Viewing Status History), and save sales and download information (see Viewing Sales and Trends).
Open the App Details page for the app, as described in Creating an iTunes Connect Record for an App.
In the App Information section under App Store, scroll to the Additional Information section and click Transfer App.
Make sure the app meets the criteria for transferring.
- If all criteria have been met, click Done.
- If all criteria haven’t been met, resolve those that are outstanding.
Enter the recipient’s Team Agent Apple ID and Team ID, and click Continue.
Verify the transfer information and contract terms.
Read the contract terms, select “I have read and agree to the agreement presented above,” and click Request Transfer.
Click Done to return to the App Details page.
Once the transfer has been initiated and is awaiting acceptance by the recipient, the app stays in its previous status, with the Pending App Transfer status added. You can change the price of the app during this time.
The transfer must be accepted by the recipient organization’s Team Agent within 60 days.
To accept an app transfer
Sign in to iTunes Connect as the Team Agent.
A notice appears indicating that an app is ready to be transferred.
Click Agreements, Tax and Banking.
In the Transfer Agreements section, locate the app being transferred in the Contracts In Process subsection and click Review.
Enter the new metadata and review it.
- Support URL
- Atom feed URL (required if the app previously had an atom feed URL entered)
- Marketing URL (required if the app previously had a marketing URL entered)
- Privacy policy URL (required if the app previously had a privacy policy URL entered)
- CCATS (a new CCATS form is required for apps that use export compliance)
- App Review contact information
- App Store contact information
Read the contract terms, and select “I have read and agree to the agreement presented above,” and click Accept.
It can take up to two business days for the app transfer to complete, during which the app status is listed as Processing App Transfer. While the app is in the transfer state, the following actions apply:
All app metadata, rights, and pricing are locked down on the transferor side and no in-app purchase edits can be made.
Any open communications on the Resolution Center page are closed out.
If the app is part of a Game Center group, no changes can be made to the group on the recipient side.
After the transfer is complete, the app is now owned by the app transfer recipient. It no longer appears in the the transferor’s iTunes Connect account.
Important: The exchange of the actual code set and build assets takes
place directly between the transferor and recipient. App IDs are
transferred automatically in developer.apple.com. To maintain a great
user experience, inform the recipient about any capabilities added to
the app, such as keychain sharing or push notifications, so that the
recipient maintains these capabilities in future updates. Keychain
sharing continues to work until the app is updated, after which point,
prior keychain data cannot be accessed. If the keychain group is
defined in the Xcode project, it must be replaced with a keychain
group created by the recipient (that includes the recipient's Team ID)
for the app to continue using keychain sharing.

Possible to rename iOS App before uploading?

I'm about to upload my app to AdHoc for Beta Testing however the Xcode project is named "MyApp" (not the actual name of the app) but I want to upload it to the app store as "MyLive". The bundle identifier is also com.myproject.MyApp but I would like to rename it if possible to something like com.mycompany.MyLive.
At the moment this is just a personal app attatched to my personal App ID but I'd like to future proof it as best as I can so it doesnt cause me any problems down the line.
As I've enrolled in the Apple Dev program using my personal Apple ID the only team I can choose is my name. However, is it possible to create a new team so that it seems like a company based around the app?
Lastly, if I upload it connected to my personal Apple ID how much personal information will be publicly visible? Is it possible to hide my email address?
EDIT: Is it possible to transfer an App from on Apple Developer account to another? Say when my current membership runs out and I set one up in the company name would I be able to transfer ownership?
Once you've created an app in iTunes Connect the bundle identifier can never be changed. If you have created it as com.myproject.MyApp then it's stuck as such. However, if this is your first upload, there's really no loss to create a different iTunes app with the bundle id of com.mycompany.MyLive.
None of that really matters though as no one will ever see this except you and anyone you've allowed on to your account. Just keep it simple.
You can rename your iTunes app name when your app is in editable state. i.e. If you've already submitted version 1.0 of the app with an iTunes app name of 'MyApp', you cannot change it for that version. But you can setup a version 1.1 and change the name before it's submitted.
It's not possible to create new 'teams'. A team is basically a developer account. You can be invited to join other teams via the owner of those accounts. In the future you can convert your personal account to a business account. It requires a bit of legal paperwork but is not hard.
The only publicly available information is what you've added when creating your iTunes Connect app. You have to add an email under review contact info, this is only used by Apple to reach you in case of questions with your app. You are also required to provide a support URL so your customers can reach you.
Everything you wanted to know about what goes on iTunes:
https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Appendices/Properties.html
Google's answer for ability to transfer apps:
https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/TransferringAndDeletingApps.html

Do you lose track record of an iOS app when you transfer it to a different owner's account?

I transferred all our apps from a personal account to an account we created related to the company. When I sign in to itunnesconnect I can't access the track record of these apps previous to when I changed ownership (downloads, devices, territories, etc.). I can't find those records either in my original account since the apps are no longer there.
Does anyone know if there is any way to recover that information?
Thanks!!
See these guidelines https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/TransferringAndDeletingApps.html
It clearly states that
To initiate an app transfer
Make a record of app information you want to have after the transfer.
Because you won’t be able to view the app information after the transfer, make a catalog report (see Requesting Catalog Reports), note dates the app was available on the store (see Viewing Status History), and save sales and download information (see Viewing Sales and Trends)."

iOS in-app purchase for a paid app

I created an app which is a paid app. Now I want to make it free so more user can download the app and use in app purchase to limit some features. But some user already paid to buy my app. How can I implement in app purchase for new user at the same time keep full feature access to old user?
If you connect to your server for registering user info, you can always create an API which executes on app launch to verify that user is full access user or not.
But I am afraid your case is not the above one.
In that case you would require to sync your data (some encrypted key in this context) with iCloud and when application is launched you can verify the type of user.
Using data in iCloud is more safer as compared to keychain as it covers device format scenario. But definitely not foolproof.
Other solution can be using Apple Purchase Receipt to verify the version of previous purchase. But this is only supported since iOS7.
Checkout some opensource libs to understand the parsing of receipts:
https://github.com/rmaddy/VerifyStoreReceiptiOS
So combining multiple strategies is the only answer for your question.
You can do this by reading the App Store receipt. The receipt contains the version number and date of the original purchase.
There are two main caveats: first, this only works on iOS 7 and above. Secondly, Apple don't include code for parsing the receipt (so it's not too easy for users to hack I understand). There are, however, onen source libraries, though using a common one will be less secure.
There are no perfect solutions to this scenario.
Suggestion 1:
Roll out one last paid update. In this update, use keychain to store those IAP flags. Then in the free version, check for these flags in keychain. This will work even if app was deleted and reinstalled with the free version later. But it will not work if the device is being reset completely whether due to some iOS version updates or user's unless a backup and restore also is involved.
Suggestion 2:
Not quite a suggestion. But I have seen similar apps on AppStore have just rollout free version. Then app incurred bad reviews from those previous users!
This is a simple example, but if you're working with a database on a server (not on the phone itself), can't you use a boolean for each feature you plan on selling, and just set that boolean to true for all users currently in the database. This is assuming true means they've bought the feature, and false means they haven't bought it.
You could run this query once after releasing your updated app, and then every user after that would have a default value of false for these features you're selling.

Giving in-app purchases to specific users for free

I have an app in the iTunes store that has full functionality. I attempted to release a Free version which contains half of the functionality, and contains a link to the full version if the user tries to use the other functions.
Apple rejected the app on the basis that rather than having two apps, I ought to have the main app released for free and have the extra functions unlockable using in-app purchasing.
That's fine; I can do this. The only problem is that since I released the full version initially, some people have already paid for and downloaded the full version. When I update this app so that it is free, it will be restricted by default. Those users that have paid for the full version will have lost the functionality they've paid for.
I don't really want to release a second version of the app since I intend on continuing to update the app and managing two release streams would be unwieldy.
Is it possible to somehow offer for free the in-app purchase to those users that have already bought the full version of my app when I update the app to the new (free, in-app supported) version?
Edit: An (unpreferred) alternative would be a way of refunding the purchases to the original buyers, along with a note explaining why. Any ideas how?
What I'd do is add a already paid option within the application itself, and then allow users to enter a license code, or email address depending what you prefer, Which you can automatically issue from their contact details if you have them or ask them to contact you if you don't, which most will as they have paid.
Now as far as the licensing and the verification of these codes you could setup a cheap VPS which verify s the code and only activates with codes that you have entered on the server, meaning you won't fall victim of Keygeners.
Just my 2 cents.
If your app doesn't currently have a username/password registration, I would suggest releasing an update to the paid app that explains to your users on an initial popup view something like:
Thank you for supporting our app. Due to changes in Apple's policies, we will be converting this app into a free app with in-app upgrades. Since you already purchased the full app, you will be awarded all features! Please input an [email_address or username] so that we can provide a painless transition.
If your app has a user login mechanism already in place (username/password), then just store those details and have the user log in later in the "free" app to unlock all of the features.
Obviously, both of these suggestions require a backend for validation, but shouldn't be too difficult to create that.
This is tricky due to section 3.3.3 of the license agreement and Attachment 2. I'm not a lawyer so I'll save my interpretation but, read them.
Another option would be to make the free version a new, different app and leave the original one in the store but unavailable. Then you can still publish updates to it but new users won't see it. Apple would probably allow this considering you are still only presenting one app to new users. The downsides are (1) you have to maintain two versions and (2) you have to start over in terms of reviews etc.

Resources