I have my flutter app in testflight. I tested it, but now I want to move to production (App Store). The problem is that I don't know how to change the environment variables in my app (in test flight is using API test IP and I need to change it to production IP)
Related
after a little bit of advice. Kind of got myself into a bit of a chicken and egg situation.
So they story is, We have recently completed a major update on some mobile apps (Both iOS and Android). These mobile apps connect to a Azure hosted app service which has also had a number of significant changes including many db structure changes. All of which is currently live in production, so I have to release the updated app service and mobile apps at the same time.
This is where the problem comes in. To make the apps avaliable for review with the relevent stores, I will of course mean I need to have updated the app service so that the updated apps work, but I can't update that until I can release the apps to the general user base.
Any advice on how to get the updated apps approved without breaking things for the current users?
You could use Azure web app deployment slot to set up staging environments.
Deploying your application to a non-production slot has the following benefits:
1.You can validate app changes in a staging deployment slot before swapping it with the production slot.
2.Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped because of swap operations. You can automate this entire workflow by configuring auto swap when pre-swap validation isn't needed.
3.After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot aren't as you expect, you can perform the same swap immediately to get your "last known good site" back.
When you have updated the app service so that the updated apps work, click swap and it will immediately swap to production without breaking things for the current users.
For more details, you could refer to this article to set up staging environments.
We recently enrolled in the iOS Enterprise Developer Program to be able to use in-house distribution, which significantly simplifies the deployment of the apps inside our company which is fairly big. Before joining we have thoroughly read the program documentation and we were aware that the new account would live completely separated from the standard account we use for the AppStore submissions.
What I'm unsure about is now what would be the best way to organize the two accounts in the developer portals. I'm mostly concerned with the bundle identifier since I'll be dealing with two different bundle ids inside Xcode for each application. All of our apps use iCloud and Push notifications so wildcard is not an option.
How do you organize this inside Xcode? Do you create two different targets or are you able to manage this with a new Project Configuration? What about iCloud entitlements?
EDIT
Just as an update I wanted to make clear that we're looking for the best solution to build an app for both In-House distribution and for AppStore submission.
EDIT2
Given that the enterprise program does not grant you access to iTunesConnect, where test users and product ids can be setup, is there really no way to test InApp purchases?
I'm not entirely clear on what you need, but it sounds like you want to be able to build your app store apps for internal enterprise use. Is that correct?
If you want to be able to build your app with two different bundle IDs you can create a custom build setting, and give it different values for your different configurations.
So for example, you could create your Enterprise configuration:
Then go to your target's build settings and add a user-defined build setting:
Give it a name like BUNDLE_ID, and if you expand the triangle you can give it different values for each configuration:
Next, open your Info.plist file and enter ${BUNDLE_ID} for the bundle id value:
When you compile using the "Enterprise" configuration, which you can do using a custom scheme (or via the command line build process if that's what you use), the appropriate bundle id will be used.
You can also configure the code signing/provisiong profile setting in the same way:
Once you do this, the correct push notification/iCloud entitlements will be used depending on the configuration.
We've been doing this kind of thing for a long time now. Our build server will generate enterprise and app store versions of our apps for each build, using exactly this technique.
When it comes to the provisioning portal, you will need to configure both app IDs separately for push notifications, iCloud, etc.
This does mean that push notifications must be sent separately to the app store and enterprise versions since they will not share the same bundle ID or push notification certificate.
The iCloud storage by default will be totally separate for the two versions. They may be able to access the same iCloud store (if you need this) as long as the entitlements are set up with the same team ID. But this may be a problem if you have two separate developer accounts.
I have a beta application that I want to show to 100+ people and I can't figure out how I can do it without the app store. The thing is with the app store it's a beta. In the app it has pages that do nothing because I want to show the people what I'm working on next.
What adds to the problem is that the application is Push notification enabled.
I'm guessing if I sent the files of the code that the certificates would change because they would have to make a new provisioning cert.
http://testflightapp.com is a great tool for distributing beta tests. As for the 100+, it will only support 100 a year as per Apple's ad-hoc constraint, up to 200 devices. To test with more people, you'll need to sign the app again with another developer account and distribute to a second list. Other options include enterprise deployment or having some testers build and deploy for themselves, signing with their own developer account.
The application update process via app store (on the device by a lambda user) is not very well documented. I've sum up all this to these questions :
what happens when the user updates his app? Is everything erased, or just some part of the app?
so what is kept, what is not kept?
how to test the application update in a development environment ?
when user updates an app, Documents folder is stored as is, including NSUserDefaults (but, sometimes user download app via iTunes and replace the whole application, crying 'OMG! update killed all my levels progress!');
Application bundle is erased and replaced by new one (anyway, it is readonly for user);
Re-deployment of new build version will be enough;
Apple's APN Service Programming Guide in the Provisioning and Development section claims that "[t]he sandbox environment also acts a virtual device, enabling simulated end-to-end testing." However I couldn't find any information how this virtual device can be accessed (e.g. how do you get a device token, how do you check the status of notifications sent, etc.) Does anyone know if this information is valid and if it is how does one go about doing end-to-end testing using the sandbox as a virtual device?
Getting a device token works the same in sandbox servers as it does in production servers - you just get a development device token that can only be used when talking to their sandbox servers. However, just like the production servers, you can't check the status of notifications sent or anything like that.
The "virtual device" wording is confusing, because it's really just a separate set of infrastructure that only talks to development applications/device tokens.
So, just talk to the development servers while you're developing your app (that is, when your app is built with a development provisioning profile) and talk to production servers when the app is built in ad-hoc or production mode. The process is going to be same.
However, be sure not to mix development device tokens and production device tokens.
Also, push notifications don't work in the simulator, so you will need an actual device to test on. If you're testing on an iPod Touch, be sure to keep in mind that it will only check for messages every fifteen minutes or so if the backlight is off.
Hope this helps!