Is there a way to officially bypass the iCloud lock on 8.1.2 (iPhone 5C) devices, outside of Doulci? Something free, and does not require dialing 112? Apparently that's an emergency number.
I need this to continue development on iOS devices.
If not, is there a way or software to forcibly downgrade my iOS version to 7.1.2, or an early hackable iOS 8 firmware without iTunes? I own a Macbook Pro, running Yosemite, if that makes it easier. I have access to a Windows machine too.
This is a legitimate question, and it's not a duplicate from the last one I had made asking for Doulci specifics. Please do not lock this unless the question becomes dead, I don't know how to contact people and ask why the questions are "Deleted". I don't understand why my last question (which was all about Doulci) was locked. I really believe this would be useful for other iOS developers who don't have $500 on hand.
Thanks! :)
If you mean the Activation Lock, then I really count on there being no way around it since IOS 8.
If you load a different os on it (i.e. jail break it) then you may have some joy, for a while, but you will need the password to get IOS 8 back on it.
The best way is to turn off find my iPhone, using the password.
If no password then you can reset the password if you have the security answers required. last resort call apple support.
Only working ways to unlock/bypass iCloud at current moment:
Ask previous owner to remove it from their iCloud account
Get previous owner iCloud account control in not legit ways/phishing
If it Clean mode than find legit Apple Employee who will remove it by GSX account request
If it Lost mode, than there is no other ways than 1 or 2 steps of this list
If device still works but linked to iCloud, use myicloud info trick to restore backup from working device. Full bypass until first firmware restoring
I have develop server that gives access to web browser - iCloud DNS Bypass, it free and works for all iOS versions. So it only bypass working at current moment, but no calls and no mobile Internet.
The only way at the moment is to Erase the SSD nand Completely which the device Has Security measures for keeping you from doing so. Thus the SSD nand would have to be replaced, then restored with IOS version you wish to install.
Related
I'm using IOS Simulator v6.0.
Device is iPhone (all iPhone devices behave the same with regards to my problem)
IOS version is 6.1
I'm attempting to download a p12 via a web app using the built-in safari browser.
When the download completes the user is automatically taken to the settings app (which I understand is necessary to complete installation of the p12) - but there is no option to complete the installation. Ive read that a Passcode Lock is required for enabling certificate imports. However, I can't find out how to enable a passcode lock within the iPhone IOS simulator.
The doc I've read says the option should be within: Settings -> General -> Passcode Lock
Except its not. Is this a simulator specific restriction? Can I overcome it?
Neil,
Yes, as you've pointed out, the iOS Simulator is not a 100% accurate replication of the operating environment found in an actual iOS Device -- certain classes of interactions that are dependent on specialized hardware (cameras, gyroscopes, magnetometers, hardware-based encryption technologies, etc.) are naturally unsupportable in a simulated environment. Other classes of interactions that would seemingly be 'software-only' kinds of interactions are also prohibited on Simulator (Push Notifications, iCloud, etc.) -- these are attributable to a couple of things:
Unlike physical devices, you do not provision the iOS Simulator. Since Provisioning Profiles include entitlements for these Apple services, there is no (current) way for Simulator to understand how to connect to your specific app's slice of these services.
Simulator does not have a unique hardware identifier, so connections from your Simulator would be indistinguishable from connections on any other Developer's Simulator.
And finally there are the class of interactions that don't fit either of the exclusions from above that can only be attributable to design decisions made by Apple. Passcode lock, for example, can simply be enabled by security-conscious iOS device users...or it can be enforced by IT departments by way of Mobile Device Configuration policies (via ActiveSync, MDM servers, etc.) Adding only the generic, non-IT-mandated version of Passcode Lock would cause intra-Simulator feature parity as only the most Generic Passcode lock behaviors would be supported, leaving MDM users out in the cold. To avoid this, Apple would then have to endow Simulator with the knowledge to support .mobileconfiguration profiles, connect and periodically check with MDM servers (thus requiring unique hardware identifiers), and ultimately include the Mail.app in Simulator to allow for Exchange connections to be setup to enforce ActiveSync managed configurations.
As you can see, the relatively simple feature quickly spiders out to a host of other iOS elements that would also need to be simulated. Taking this to the most unlikely, extreme edge case, Simulator would become a full-fledged software-only iPhone where you receive calls and texts, check email, etc. directly from the iPhone shaped interface on OS X...not an experience Apple would like for users to have even though those users are their 3rd-party developers.
Though there are some interactions we can easily deduce the rationale for their omission from the simulator, only Apple really knows why they elected to exclude other interactions from Simulator.
So, back to your questions:
Is this a simulator specific restriction?
Yes, this is currently not supported in iOS Simulator as of Xcode 4.6.2.
Can I overcome it?
To the best of my knowledge, no.
I do, however, think that your lurking question about installing a Certificate in Simulator is something that you can do something about -- In fact, I installed a self-signed certificate authority into my Simulator to do some security testing about 2 months ago based in large part to some of the work presented by the Developers of the Charles web proxy.
If you download their shell scripts you can see how they injected self-signed certificates into the Simulator keystore -- assuming your ultimate goal is to get a certificate installed, you may be able to apply a similar process to your own certificate.
Do make sure to backup the default keystore; It would be really easy to accidentally break the binary data in that file and render your Simulator useless for all SSL connections.
As is likely tacitly understood, this is not a supported operation in iOS Simulator -- tweak Simulator at your own risk.
Good luck, and if all else fails, push your app to device where you can definitely get a certificate installed.
I have to restrict a Free app from being downloaded or installed for a 2nd time on an iOS device, as I would like to user to purchase the paid version of the same. A first time user of the free App can download the Free App and install it on their iOS device, but after using the Free App for certain number of times, the Free App will work with limited functionality as I would like to promote my paid version, so I prompt the user to buy my Paid version of the App. At this time the user can delete my Free App and Re-Install the same from either the iTunes store or the iTunes on their computer or iCloud backup.
Question is how can I restrict the user from re-installing the same Free App on their iOS device a 2nd time ?
Is there any way to tell the iOS on the user's device to stop the 2nd time install of the same Free app ?
Or is there any other way to achieve the same results ?
Thank you.
You're unlikely to reliably get past Apple's review process with these restrictions.
Free/lite apps are supposed to be fully usable apps in their own right. So, using a todo app as an example:
You could limit it to ten TODO items
But you'd get into trouble if it stopped working after ten days
Clearly you can also limit in terms of what functionality you offer. My apps, for example, only allow editing in the paid version; the free one is read-only.
I'm not sure that you can reliably do what you want. (What about if I have to wipe my phone and restore from a backup? Does that count as reinstallation?) But even if you could, it wouldn't necessarily be a good idea.
i think the recommended way is to use in-app purchase. You can enable a full Version to the user when he buys it. So there is no reinstall needed.
I'm not sure why you have the requirements you do, but this does not fit the model of the App Store. You are likely to have your application rejected, even if you were to find a way to do this.
If you (or your stakeholder) are insistent in this approach, maybe the App Store is not for you.
We have an iPad app running in a kiosk mode deployed across multiple physical locations. We'd like to have a solution where any updates to the app are pushed automatically to the device so that the client does not have to touch each iPad they have.
Our client has an existing MDM software that notifies the user if there's an update, but since it's intended to be a kiosk we don't want the general public to actually do the update by themselves.
Does anyone know if this is possible at all?
Thanks,
Teja.
Edit: As of iOS 7, you can now force an app update through MDM software.
(Previously for iOS 6 and below):
Sorry, but with even with the enterprise program and an MDM server, you cannot force an update on an iOS device.
Your best bet would be to configure the updates so that they run automatically just by clicking once and accepting the update. That way it is safe for anyone to accept.
Sources: Own knowledge and this site.
I know that as of iOS 7, this is no longer the case. If your app is managed via your MDM solution, you can force an update.
I am researching UDID alternatives, and OpenUDID seems interesting.
I have done some testing and if I remove the app, and re-install again, the value of OpenUDID remain the same, I am just wondering how they do that and is the value always guaranteed to persist if I don't hard reset the phone.
They do NOT use the keychain, they use the UIPasteBoard, which is a shared OS construct that persists across device restarts. From the doc:
"system pasteboards are persistent across device restarts, application uninstalls, and restores."
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIPasteboard_Class/Reference.html
Giving a quick glance at the naming conventions they use, I'd say they are almost certainly using the iOS keychain. This is the same as the OS X keychain, except it doesn't allow end users direct access the way Mac OS X does. Even if the app is uninstalled, this information will not be removed. It is stored in a controlled environment to prevent jailbreakers from getting it.
I would suggest BPXUUIDHandler.
I sent an app using it 5-6 days ago and the app is approved yesterday(by Apple, which means it passed 1 May, 2013 - lose your udid's) , it persists unless the device is restored. I used it in 5 or 6 apps of mine and never had an issue with it.
I would find useful, in some cases, and under the user's permission, to block the device so only the running application can be accessed unless the usrer's password (pattern or whatever is used to unlock the session) is introduced.
I guess the mecanism should be something like: The application asks the os to do this, the OS asks the user for permission and then the application asks the device to block the application on "exit" or standby (or both).
This would be useful for using an iPhone or iPad as a device for public use. One example could be a Library where visitors can see the book list and some previews in the device. In this case, you don't want the user to access any other resource/application in the system.
Does it make sense?
What your asking is there any type of kiosk mode for iOS devices.
The short answer in no. The longer answer is if you're using a Jail broken device you might be able to relaunch the app on exit, but it would take significant R&D.
I hade a client ask about this last week, after some investigation and thinking I told her,
It's best to look for a case that blocks the home button. Or some kind of security bracket. It'll be cheaper and easier.
Also any App you create with this functionality would be rejected form the App store.
If your looking for advice on programming Jail broken devices there is a Stack Exchange proposal you can follow.
Supposedly there's a way to have a "kiosk" mode with a .mobileconfig file. Both of these articles talk about it, basically covering the same territory:
http://joris.kluivers.nl/blog/2012/03/02/kiosk-mode-for-ios/
http://rick-hawkins.blogspot.ca/2012/01/turning-ipad-into-kiosk-device.html
I was looking into this again and found out that iOS already supports the feature. It is called Guided Access, it was incorporated on iOS 6, it does not require jailbreak and can be used for any app installed on the device.
It makes sense, but I don't think you can do that without jailbreaking the phone. In iOS, the home button cannot be overridden by applications. Besides there is cheaper hardware out there for kiosk-style applications.