When building the app I added the valid architectures architecture as armv6, armv7, armvs7 and architectures as standard architecture (armv7 and armv7s). Also switched the build active architecture only to NO. Adhoc installation hangs with the status installing message (attached screenshot). I have added the UDIDs properly and was successfully able to push builds like this to those devices prior to iOS 7. This is reproducible with 4 devices so I believe this is something to do with the way I am building this. All the phones uses latest iOS 7.0.2. Additionally I tried to make the target os to iOS 7 and added arm64 to valid architectures. Still no luck.
Please note that since iOS7 apple blocked API access to UDID.
In other words: the applications formly used to send UDID no longer valid, and you should use iTunes to find out your and your friends UDID.
Hey so there is a lot of possible solutions to the problem. Here is one thread.
https://discussions.apple.com/message/23033175#23033175
Another thing you can check is to see if the wireless connection you used when first installing the ad hoc distribution is if the wireless network setting block cookies and filter multicast were turned on. If so that can cause this issues. I have found that a lot of corporate networks can have this turned on.
Related
I spent many hours trying to figure this issue out. Apple continuously accepted my uploaded binary when I was submitting my app through XCode4.2, yet only to declare the binary invalid minutes later. It turned out that it was because I had placed the "Default-568h#2x.png" in my resources folder in an attempt to support iPhone 5's splash screen and eliminate "letterbox mode" (black top and bottom bars)... I am using a 2006 MacBook Pro, and thus am unable to upgrade to Lion OS or Xcode4.5. Also, I am able to build AdHoc versions for my customer that runs just fine on the iPhone 5 (filling its entire screen).
Does anyone know of a workaround I can implement to get Apple to accept my binary while still being able to support iPhone 5's larger screen (no black top or bottom bars)? If I re-name "Default-568h#2x.png" I am able to get Apple to accept my binary, but will I lose compatibility with iPhone5?
I found the following link in my search, which seems to suggest the startup image has nothing to do with the iPhone 5's letterbox mode, and can be labeled any name. However, I must admit, I am rather lost when the writer begins discussing 'viewports' and 'media queries'...
http://www.mobilexweb.com/blog/iphone-5-ios-6-html5-developers
Thanks in advance for any help you can offer!
Apple has made a deliberate decision to only allow two types of apps:
Apps built with XCode 4.4 and earlier, built for iOS up to version 5, including support for armv6 (required for iPhone 3G) but without support for iOS 6 and without support for the larger screen of the iPhone 5.
Apps built with XCode 4.5, built for at least iOS 4.3, possibly supporting the larger screens (Default-568h#2x.png) but without support for iOS before 4.3 and without support for the armv6 architecture (required for iPhone 3G).
All others apps are now rejected if you upload them to the App Store. Your app is rejected because it's includes Default-568h#2x.png and one the following things: either armv6 support or support for iOS before 4.3.
Without XCode 4.5, it's impossible to create an app the support the larger iPhone 5 screen and is accepted by Apple.
Some people have managed to build and upload applications the support both iPhone 3G and iPhone 5. But this is very tricky and requires a parallel installation of at least XCode 4.5 and one earlier version.
Update:
If I'm not mistaken, the crucial points for supporting the larger screen are:
The launch image Default-568h#2x.png
The setting of Base SDK being iOS 6 (or later)
If you add the launch image without setting the Base SDK to iOS 6, iTunes Connect will reject you app:
"Invalid Launch Image - You app contains a launch image with a size modifier that is only supported for apps built with the iOS 6.0 SDK or later."
Without XCode 4.5, you cannot select iOS 6 as the Base SDK.
I was able to install iOS 6.0 SDK on my XCode v4.2 following these instructions:
Is it possible to get the iOS 5.1 SDK for Xcode 4.2 on Snow Leopard?
Afterwards, I could create a binary with the below attributes that Apple would accept.
The launch image Default-568h#2x.png
The setting of Base SDK being iOS 6 (or later)
I have have a Mac mini from 2006, running Snow Leopard, Xcode 4.2. I was having the exact same problem with my submissions last night (May 2, 2013). Organizer uploads the app, and says all is fine. Within a couple of minutes The email below comes through. I did what the email suggested. Then I double checked, triple checked all settings, recreated certificates/profiles....still invalid binary.
Early in development, I was able to crack a dmg to get iOS6 installed on my machine. I put Default-568h#2x.png in my app. I tested ad hoc installations on a 5th gen iPod Touch - everything worked fine, BUT Apple won't accept my app.
I was going to get a new mac this year anyway. I'm heading to the Apple store to get one tonight. Here's the email from Apple:
Dear developer,
We have discovered one or more issues with your recent delivery for "Gazoodle Colours". To process your delivery, the following issues must be corrected:
Invalid Signature - Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose "Clean All" in Xcode, delete the "build" directory in the Finder, and rebuild your release target.
Once these issues have been corrected, go to the Version Details page and click "Ready to Upload Binary." Continue through the submission process until the app status is "Waiting for Upload." You can then deliver the corrected binary.
Regards,
The App Store team
Update: Got a new macbook pro, built my app with the latest Xcode (4.6.2) and resubmitted the app. My app is finally in the Waiting for Review state. Wasn't sure buying a new computer would solve the problem, but it was a good excuse to upgrade the hardware, and it actually fixed the invalid binary issue!
I'm making an app that requires multitasking. Is there a way to compile an iPhone/iPad (universal) app so it excludes devices that do not support multitasking. I know iPhone 1, iPhone 3G and iTouch 1-2 do not support multitasking but I haven't found a way to build my app so it prevents people to download the app from the app store if they have one of these devices.
I was thinking to simply set the "Architectures" setting to armv7 on Xcode but I'm not sure if this will work and if it will have any other consequences.
Any help will be appreciated. Thanks!
You can set the minimum API level supported to be iOS 4.3. This version only runs on devices that support multi-tasking.
You should check in your application for multitasking support and fall back to a non multitasking alternative if it is not available.
Suppose you change the supported architectures to include ARM7 upwards. If you do, you need to find out what happens if somebody attempts to deploy such an application to an incompatible device. If iTunes stops them from doing it, that's fine and it's the right answer. But if iTunes lets them do deploy the app and it crashes when they try to run it, it would be far better to do the test for multitasking support and display an alert telling the user why your app won't work.
Go to targets section of your project--> navigate to Build Tab-->Go to Deployment tab & select IOS deployment target as 4.2. It will not run on IOS versions earlier than this.
I'd like to distribute my app to a beta tester (ad hoc distribution). Do they need to have the apple developer's license? Do they need a Mac? Or is it enough for them to just have iTunes?
also, is the ad hoc distribution process different for Xcode 4? I know the process for submitting it to the app store is different.
Taking your questions in order:
Beta testers don't need a developer licence.
Nor do they need a Mac.
They don't even need iTunes. (You can deploy via a link they open in Safari on the device itself.)
The process is somewhat different for Xcode 4. (It's quite a bit easier that said.) Whilst I don't like to link to off-site resources, there's a very good blog article that details ad-hoc provisioning using Xcode 4 at: http://diaryofacodemonkey.ruprect.com/2011/03/18/ad-hoc-app-distribution-with-xcode-4/
ad hoc distributin works via itunes. only the perso who makes the app needs a developer account. you will need to provision the app you make to all the devices you want it to install on. via itunes this involves the insane process of clicking on a long serial number which does not look at all clickable to reveal an even longer uuid.
not sure about xcode 4 compared to anything else. only ever used one version of xcode.
No, beta testers don't need to be registered developers.
To make beta testing of iOS apps really simple, please have a look at Hockey Framework:
https://github.com/TheRealKerni/HockeyKit
Beta testers receive their test app over the air and the Hockey Framework even informs them automatically, when a new beta update is available OTA.
Additional reading:
http://www.buzzworks.de/blog/announcing-developer-framework-hockey
http://jeffreysambells.com/posts/2010/06/22/ios-wireless-app-distribution/
No, they don't need a developer licence. Actually, if your user has iOS 4 or higher, they don't even need iTunes. You can use something like iOS Beta Builder. They do, however, need to tell you the UDID of their device. You can get that in iTunes or there are apps in the App Store that find it.
No, beta testers don't need to be approved iOS developers. You will still need to whitelist the UDID of the testers though.
I'd suggest you use Diawi to share your ad-hoc builds with beta testers wirelessly without iTunes, I've tried several solutions and I found it to be the simplest of the pack.
synching
Also try testflightapp.com to distribute your Adhoc builds. You can keep track of the installs and even crash logs.
P.S I don't work at testflight, but find it a lot helpful for beta testing.
I want to install an AdHoc IPA file to an iPhone, but I don't want to back up the apps of iPhone into iTunes, because the iPhone is not mine, and there are too many apps in it. Is that possible?
You could also use Xcode (at least Xcode 4, haven't tried it with earlier versions):
Open the Organizer and select 'Applications' under your device in the Devices tab. Now use the Add button to add your ipa to the device.
This web app may be what you need: http://testflightapp.com/
Take a look at Hockey, from the project description:
Hockey is a iOS Ad-Hoc updater framework. It can be used for all apps that target the Apple AppStore and improves the beta testing process dramatically. All beta testers. It consists of two components, a server and a client framework.
The server component is required for all scenarios. But it also can work standalone without the client library. It provides a web interface which beta testers can use to install the latest AdHoc provisioning profile and also the latest beta version via Safari right from the device. One server installation is able to handle multiple applications via different bundle identifiers
This procedure was published this morning, so I am not sure if it works as advertised. Basically it talks you through setting up Adhoc distribution OTA in something like ten easy steps.
We're developing an application that uses CoreLocation as a primary feature, where need to poll the GPS over an extended period of time. Everything works fine when we install via build&run in Xcode, but whenever its installed via adhoc using hockey (ipa generated using build&archive->share_application->distribute_for_enterprise), something very odd is going on with CoreLocation. Here are the problems we're experiencing; (1) the "Allow xxx to access your current location" dialog is never displayed, (2) the location icon on the taskbar is never shown, and (3) the delegate method, locationManager:didUpdateToLocation... is never called.
To make matters even more confusing, this issue is only reproducible on the developer devices. Beta testers are not experiencing this. We have tried removing all provisioning profiles from the developer devices and from Xcode, but the issue still remains. We have also verified that we are building with the lastest provisioning profile. I was only able to install via adhoc onto my dev phone after I completely wiped it and set it up as a new phone in iTunes.
Has anyone else experienced this issue or something similar? Any suggestions/recommendations?
Tested using Xcode 3.2.4 64bit and iOS 4.1 (8B117)
Possibly related to iphone Location Services code that works on OS 4.1 in appstore?