I've been using using Testflightapp.com to deliver beta version of my app for years and now I'm considering to use the itunesconnect version of testflight because of its advantage of 1000 external beta users.
Anybody know what is the difference of these two versions? Should I continue using the testflightapp.com version (because I'm already comfortable with the current system) or should I move using itunesconnect version immediately?
TestFlight Beta Testing (iTunes Connect version)
Uses AppStore provisioning profile which mean you don't need to manage UUIDs
Builds are distributed through an iOS app
The install expires after 30 days
You're allowed to install up to 25 internal users (by adding their emails in itunesconnect)
You can install up to 1000 devices, but app needs to go through a review process (often takes 2 to 3 days)
We are currently using both TestFlights, the original TestFlight for internal testing which gives us 100 devices. We use the "new" TestFlight for external beta testing to take advantage of deploying to 1000 devices. We'll probably eventually move to the new TestFlight as I predict Apple killing the old service in the future.
Related
I'm working on an application that I want to test on iOS 7, but I have no devices that can run iOS 7.
A friend living far away from me with an iPhone 5 is willing to beta-test the app.
I've added his UDID to my developer profile.
What else would his phone need to test the app properly?
I think he needs the provisioning profile/certificate installed on his phone?
Would his phone then be able to install the iOS 7 beta without any problems?
From my understanding, phones that are not tied to a developer account are bricked if they try to install the beta.
General Notes
Might I recommend you look into http://www.testflightapp.com? Among other things, it will ensure:
You have his UUID without error
He can download your app
You can collect feedback, crash reports, and "checkpoint" information about his usage.
You can enlist the help of others as well using this (and similar) services, making this whole problem a lot easier to manage now and in the future.
How to enable iOS Beta version installs:
Once you're sure you have his UUID, put it into your developer account's device list using the Apple Developer Portal, and he will be able to install iOS 7 Beta using iTunes. You may want to either add his apple ID to your developer account so he can download the beta, or otherwise arrange to get the .DMG to him.
How to distribute your app:
You need to create a distribution profile for your app which includes the device UUID you received from your friend. This can be done on the Apple Developer Portal under Certificates. After you create the profile, download and install it on your development computer. When you create an IPA, be sure to sign it with this profile. You can then use testflight, or some other means to distribute the app.
I'm developing an iPhone/android app and, in the case of iphone one, I need to host it asap. I am about to finish it but the average time to be published in the AppStore is about 7 days once been aproved. I was looking for any othe host but I'm not sure if they would be work as AppStore, I mean: downloading by everycustoner without doing throught Cydia or things like that.
Any suggestion or experiences?
Thanks
If you have an enterprise account, you can use Enterprise Distribution for in-house apps. But you probably don't, or you wouldn't be asking this question.
If it's a very limited number of devices and you have personal contact with all potential users:
You could deploy it on devices yourself.
You could use ad-hoc beta distribution (made easy with TestFlight, for instance).
Other than that - there are no other legitimate options.
If you want widespread, "ordinary" distribution of a native app on iOS, you'll have to go through the app store, period.
Other than for time-limited plus number-of-devices-limited beta test distribution (Ad Hoc and/or testflight), the only host option for unlimited distribution of an iOS app to ordinary customers with stock devices is waiting for an app to be approved and hosted on Apple's iTunes App store.
I currently have an app in the app store that works for iPhone users running iOS version 3.0 or newer. My next version of the app is going to use ARC, so it will only work for users running iOS version 4.0 or newer.
According to this answer, the users will be able to download the newer version, but it just won't run when they try to run it.
Is there any way to prevent users who can't run the app from even downloading it from the AppStore?
I haven't tested this recently, but in February 2011, and iOS 4.x, I had users who couldn't download my app as there device wasn't running the required version of iOS.
They received a nice explanation message on their device, courtesy of the App Store app, when trying to download the app directly to their device.
I'd be very surprised if this wasn't still the case.
So, set the deployment target in your target build settings, and let the App Store / iTunes take care of who can install it.
That was for new installs, and it be different for updates (rather than new installs) but again I'd be surprised if this wasn't handled by Apple for the sake of a better user experience.
UPDATE
I dug out my old iPhone 3 which reached the end of the road at 4.2.1 and resynced it with iTunes - the latest apps that require 4.3 etc are ignored, and are not overwritten with incompatible versions, as I would expect.
I also tried to update my own app (I'm a developer), requiring 4.3 and above, from the store via the device itself, and got a polite pop-up alert saying the app requires iOS 4.3 and above, again just as I'd expect.
The app was previously compatible with < 4.3, and somewhere along the line I bumped up the minimum iOS version requirement, so it is definitely possible.
So, you should just set your updated app's 'deployment target' version appropriately, and it will only be updated on compatible devices.
No. A new higher minimum Deployment target will prevent a user from installing an app on a device with a lower OS version, but will not prevent them from downloading the app using iTunes on their Mac or PC, even though they can't install the update once downloaded.
I have an application that I would ideally like to run on all iOS versions, however I think Apple accepts apps only from a version and above (3.0 I think, but not sure). So my question would be, what's the minimum iOS target version you can send in review (and get accepted). If anyone with greater iOS publishing experience would answer my question it would be great and maybe point out some places where I can read about it.
Many thanks!
Sometime last year, an Apple DTS employee posted (and later clarified) on the iOS Developer Forums that the App store would no longer be accepting apps with a Deployment Target lower than 3.0. That might indicate that a lower Deployment Target has or will become grounds for an app to be rejected.
I would never set the Deployment Target lower than that of the lowest OS version among the devices I plan to use to test the app before submitting it to the App Store.
Also, the installed based of devices which haven't been upgraded to 3.0 or above might be too microscopic to be worth a developer's time or effort (unless you happen to still have and use one for some reason).
ADDED in 2013: App store submission now requires that the app support the 4" display, which requires iOS 6.0 or later, which allows a minimum deployment target no lower than iOS 4.3
To back up what hotpaw2 indicated, this is from the News and Announcements for iOS Developers on June 29, 2010:
Make sure that your applications are
compatible with iOS 4. All new
applications and updates to existing
applications must be built with iPhone
SDK 4. In addition, the App Store will
no longer support applications that
target iOS 2.x.
ok... strangely Im having a hard time verifying this... but it's my belief that you must build your app with the latest base SDK (4.0), but you can target an IOS version all the way back to 2.0. Ill continue to try to verify that.
You can only build your apps with the SDKs you have installed.
Since XCode will nuke your old SDKs whenever you upgrade (unless you install XCode elsewhere), it is assumed that you will always be building using the latest stable SDK version. This is in contrast to, say, Android, which will always retain SDKs whenever you upgrade.
Your deployment target can go back as far as you want, right back to 2.0 - but you may find it difficult to actually test it on that platform! Most people would just target 3.x upwards, which gives you as close to 100% coverage as makes no difference.
Let's say we have an application with a deployment target set to 3.0 and we want to raise the deployment target to 3.2. Normally, the App Store won't let the App be installed on devices with an IOS version less then this, but what about devices which already had the App installed prior to the update? Will they see the update but won't be able to install, will they just not see the update or, heavens forbid, will be able to install and the app just won't start?
I searched everywhere for this, but I can't find anything about raising the minimum OS version for an app update.
Thanks!
From my experience those updates just won't show up as available.
When I upgraded OS on my device from 3.1 to 4.1 about 10 available updates appeared immediately in App store app - so that should be the actual behavior.
In addition to only showing supported updates, the store now offers the "last compatible version". This lets people download an app even if their device doesn't support the most recent version. Unfortunately this means that some people could still download an older version with bugs you have already fixed. There may be a way to disable this, but none of my app updates have introduced new requirements, so I can not test.
It's nearly a safe bet that they won't be allowed to install it. A similar situation is iPad apps or Mac apps which won't display in the App Store on iPhones and iPods.
I say nearly because the updates should not appear to older users on their iOS devices. The risk, however, is when users sync with iTunes, or if they update with another device. The new version of the app is now associated with their account, and will ruin the install on the older device if they try to sync it with iTunes.