I am trying to download applications from my Worklight Application Center Client (5.0.5 version) on an iPhone 5 runnning ios 6.1.2.
9 times out of 10 the download and install of the application will fail, whilst 1 in 10 times it will download and install correctly.
I have also tried using an iPhone running io5.1 and the install works fine. It also works fine on an iPad running ios5.1. It fails on another iPhone running ios6.0
I have checked issues such as signing of the apps and if I am using a correct UDID and I can say that these are not causing the issue, especially when you consider that it works some of them time.
It seems to be something to do with ios6 specifically.
Has anyone else seen this kind of behavior or can offer any help in terms of resolving it?
Thanks in advance,
Joe
The situation with iOS 6 seems better with Worklight 5.0.6, to be released in the near future.
Related
I'm trying to capture UI Automation script with a sample project. I use Xcode 6 on OS X 10.9.3 and iOS 8 SDK, trying to capture script on iOS 8 simulator, but getting following error:
Script capture is not available on this device
SDK is still in beta, so maybe that's a common bug there. Did anyone else face this bug? Or maybe there's a workaround available?
When I try to do the same things with Xcode 5 / iOS SDK 7.1 everything goes fine.
You should enable UI Automation in the device settings: Settings -> Developer -> Enable UI Automation.
It works for me.
It's a known issue to apple and that they need to fix this which surely they will...
Check this out... Bug has been filed
http://openradar.appspot.com/radar?id=6099734162833408
I'm trying to install my iOS app on to devices running iOS 7.0. I can install them on my iPhone 4 with iOS 5.1 jailbroken. But currently I'm not able to do so on a friend iPad 4 with iOS 7.0.
For installing them on JB devices I'm using JailCoder .
It works without any problem and I can code and compile my test apps, and put them on JB devices without any effort.
Recently trying to investigate possibilities I found an application named PP25 for Windows, it is a chinese application and it is said to be able to install cracked apps on NON-JB devices.
So i tried to see ig it works somehow, I was able to get my apps converted as ipas from my phone and download them to desktop with it, and i can then upload on other JB devices, thanks to a Cydia application named AppSync, pretty good indeed, but I tried and wasn't able to install them on iOS 7.
That was disappointing, I made additional tests and it appears that the PP Assistant application is able to install cracked apps on iOS 7.0 too, but not my unsigned apps (fails to verify the app rights).
Indeed there is a section in the chinese application where you can download and install commercial apps on iOS 7.0, so there must be a trick they use to re-sign the apps to make it appear as it's a legit app and thus be able to upload to the device even if not jailbroken.
If someone has any idea of what they actually do to make this happen, this would be very useful to know to test apps without JB on every device.
Non-jailbroken devices require valid code-signing to execute binaries. Either wait for a jailbreak to surface for iOS7.X, or find a code-signing service (they are available out there).
Using Xcode 7, you can install your app to your device using a freely available Apple ID.
Free On-Device Development
Now everyone can run and test their own app on a device—for free. You can run and debug your own creations on a Mac, iPhone, iPad, iPod touch, or Apple Watch without any fees, and no programs to join. All you need to do is enter your free Apple ID into Xcode. You can even use the same Apple ID you already use for the App Store or iTunes. Once you’ve perfected your app the Apple Developer Program can help you get it on the App Store.
See Launching Your App on Devices for detailed information about installing and running on devices.
Source
We've been working on getting our app to work properly with all the changes in iOS 7. Particularly the colors and layouts of things. But these changes are still in development.
The version of our app in the app store has none of these modifications. When testing locally, it works on iOS 6 fine and looks horrible on iOS 7. Yet, upon downloading it from the app store and installing it on an iOS 7 iPad, it seems to work just fine -- just as it used to in iOS 6 (!). We are wondering if there is some "compatibility flag" that the app store folks can switch, which means "not ready for iOS 7 -- use compatibility mode"? I'm not sure how else to explain this. Wondering if anyone else knows?
Our app:
http://appstore.com/cedarssuite
Summary: running via the simulator on iOS 7 or on a development iPad that has iOS 7, the app looks horrible. But downloading the approved app store version and running on iOS 7, it works just fine. Why?
A note: This is no longer correct. Since February 2014, Apple only accepts SDK7 builds
That's normal. all the old apps work fine on new iOS versions since those app. Base SDK set to that old version. in your case (iOS 6.0). They will run using old sdks. But, when you built with the new sdk (Base SDK 7.0) they look horrible as you said and some times they crash. because of layout changes and controls behaviours in the new iOS.
You are only asked to build with the new sdk to take advantage of the new features.
keeping your app. built with the old versions doesn't seem to have disadvantages other than new features. since apple still accept publishing apps with old sdk back to 4.3.
If you set the base SDK < 7, it will use the old iOS 6 style. Of course, that basically requires you compile with an old version of Xcode, and you can't use iOS 7 features, even when running on iOS 7.
I just upgraded to xCode 4.3 and used it to generate a new revision of an iPad app about 50 beta testers have been using for several months. I distributed the beta app through TestFlight as usual.
Most testers upgraded with no problem, but several testers are getting the TestFlight message "You have not permitted this device to install this build" when they try to install the new rev. I've never seen this message before. Their iPad UDID is definitely in the build's embedded.mobileprovision file and everything was working working fine with the prior revision.
What am I -- or the testers -- doing wrong and how do we correct it?
Hi i experienced the same and it seems that you must generate your mobile provisioner profile from Xcode(instead of Apple dev site for example) and you should update your App permissions (TestFlight) with this same provisioner profile that you just generated on your machine so basically the machine that generates and archive the apps using Xcode must generate the provisioner profile and then you should update your testflight app permissions with this file.
Does that make any sense?
Hope this works for you testflight is really nice to use, i faced same problems with all of my apps and hardware devices (testers all around the world)
Thanks
Turns out this is apparently a bug in Testflight. I tried to resolve the issue through their support forum and multiple emails with no real answer. I did not want to switch services as my testers knew the Testflight system well. But eventually switched to Diawi. My testers were able to install the app using Diawi with no problems.
I have a problem with an app that works perfect on my iPhone 4, and on my 3Gs but both are on iOS 4. BUT, when a colleague installed it on his 3G with 3.1.2 on it... it crashes on startup.
Is there someway I can test to install the app in a 3.1.2 simulator of some kind?
He didn't send me his crash logs yet.
Best regards,
Paul Peelen
I haven't done this for the simulator, but you can find links for the old SDKs here:
http://chris-fletcher.com/2010/08/28/howto-install-iphone-sdk-2-0-3-1-for-xcode-3-2/
You should be able to install the old simulator SDKs and have them show up in the simulator menu.
Dealing with multiple SDKs has proved to be extremely painful in my experience. If you end up installing an old SDK, I'd recommend you install it in a separate "Developer" folder.
In my opinion, the best way to deal with 3.x debugging is to get your hand on an old iPod touch with 3.x installed. You can get one for pretty cheap from a local classified ads site and it really makes 3.x debugging a lot easier.