A friend asked me to find a way to change the plist property LSApplicationQueriesSchemes from within the iOS app itself to added new schema url at runtime. The app is distributed with an Enterprise account. I told him this is impossible for me, but I don't find anything about it to provide an evidence. Could someone provide me some useful information (e.g. a link) to support my thought?
It's not possible. This is a measure Apple explicitly added to prevent developers from abusing canOpenURL to figure out what apps users had installed. Certain company was misusing this method - even updating their list dynamically - to learn what apps users had and installed and because of this Apple decided that your app should try to open other apps that it has defined at development time only. Even if you did find a way around this, Apple would most definitely fix it in the next release and break the app from that point onwards. Furthermore, the Info.plist is in your App Bundle, which is read-only.
Related
This question is not really technical in nature but it is clearly answerable with yes/no and so I hope its fine if I ask it here on StackOverflow.
My scenario is as follows: In order to share code between iOS and Android I'm using C++ for much of the app's logic. I'm about to start writing network code for both platforms and I plan to utilize OpenSSL or one of its derivates (LibreSSL / BoringSSL) to be able to do HTTPS calls.
OpenSSL/LibreSSL/BoringSSL would be statically linked into my app and periodically be updated by releasing a new app version.
However, I'm unsure about whether Apple would accept such an app in its app store or not. As far as I know they take a closer look at what is inside the app and I want to prevent a situation where all code is written but eventually rejected when attempting to publish the app to the app store.
I'm looking for a clear yes/no answer whether Apple accepts such apps nowadays (2019). Preferably this answer is coming from someone who actually knows the answer i.e. from someone having done the same recently (2018/2019).
Did anyone recently succeed in publishing such an app into Apple's app store?
Not only does Apple allow this, that's exactly how one is supposed to use OpenSSL in an iOS app. The operating system doesn't provide OpenSSL for the apps, so the apps need to bring their own one.
You'll probably need to declare the use of encryption to comply with encryption export regulations. It is, however, required even when using the system encryption like TLS.
I am planning on using DeviceCheckor indentifierForVendor to ensure that the same device is not being used to redeem multiple times the same gift (free money for example sake) offered to new users. I am wondering however, if it is possible to trick this system on a jailbroken device? Or using a custom simulator or a botnet (do iOS botnets exist?)?
I haven't tried it myself, but I think it is possible to change the bundle identifier, resign the app and side load it to your device.
This will change the change the identifier for both DeviceCheck and indentifierForVendor.
Now, for this to really affect you, the user needs to get a hold of the ipa. Which is getting increasingly difficult with the newer versions of iOS.
If you are interested in trying what I've discussed, refer to this link.
https://coderwall.com/p/qwqpnw/resign-ipa-with-new-cfbundleidentifier-and-certificate
And probably AirSign (much easier). Its a paid app for the Mac. https://www.macupdate.com/app/mac/51845/airsign
I am aware that we can block safari content using swift code. I am interested in finding out if we can restrict install of certain apps from AppStore using similar approach ?
Also, is it possible if we can restrict a user from deleting the app from device (not from phone settings but from code) ? Even if Apple does not allow that to publish such app, I am looking for a solution as a part of research.
There are two things you mentioned.
First, can restrict install of certain apps from AppStore
Using Swift code I feel there are no Public API provided by Apple for the developer till now but there is a similar way that is called Device Enrollment Program.
The Device Enrollment Program (DEP) is part of the Apple Deployment
Programs (ADP), which help businesses and educational institutions
easily deploy and configure iOS and OS X devices. DEP provides a fast,
streamlined way to deploy institutionally owned iPad and iPhone
devices and Mac computers that are purchased directly from Apple or
participating Apple Authorized Resellers or carriers.
For more visit this developer guide.
Second: restrict a user from deleting the app from device
Same response for that, till now no Developer API, but lets say if we see this as a part of research and we develop some POC still, it does not make sense for me at all (It's my device and I install the app for making my life easy and better if I don't want to use it anymore, I need an option to delete it) and I don't think so this will be possible in future as well because the USP for iOS device is user experience and we can't make this like that.
I also want to hear something from others and if possible give the use case why you are looking a solution like that.
I hope this will help.
In our applications the user autentications is based on the serial number.It seems that in ios 8 it is not possible to get the serialnumber.Is any other way?
Thanks in advance.
Apple deprecated access to a unique-per-device UUID (known as uniqueIdentifier as of iOS 6. As of iOS 7, they also blocked access to MAC querying the address, and other sorts of unique identifiers. Sometime between iOS 6 and today, they started rejecting any application that accesses this property.
There are two replacement APIs that might help: on UIDevice, there is identifierForVendor, that is consistent across your apps. And there is also an entire framework, AdSupport, who's job is to provide an identifier that can be used for advertising networks. This identifier has the limitation of people can change it whenever they want, so you cannot rely on it being consistent across multiple launches.
The hint Apple is trying to pass on here is "you cannot consistently, uniquely identify people per device across multiple apps that are not your own".
In addition to zadr excellent explanation I would like to not iCloud as another possible solution:
Simply store a value (as file or key-value) in iCloud. Only disadvantage of this approach is, that you will have to add the iCloud entitlement to your app if your app does not use iCloud yet. On the other hand there are some advantages
Very little / none additional effort necessary if your app already uses iCloud
No additional Frameworsk like AdSupport necessary
The saved value will be consistent between devices and app re-install
More than one app can share the ID by using the same iCloud (ubiquity container)
Of course in some cases this might be a little overdone but in other this can be a handy solution.
I would recommend using uniqueIdentifier as suggested above but saving in keychain. This way its reliably available to you all the time, and can be used to track the user.
I'm looking for a way to retrieve the UDID on devices running iOS 6+ (Enterprise deployment only - no app store limitations).
Calling the (now private) method uniqueIdentifier returns the 'vendorIdentifier' starting with 'FFFFFFF'. Unfortunately thats not what I want.
Any ideas? Is there another private method or something?
Thanks in advance.
I recommend you reading this article. To sum up:
The previously deprecated uniqueIdentifier now works like vendorIdentifier on iOS 7+, so it's no longer usable even for Enterprise Apps
OpenUDID cannot be shared between Applications on iOS 7+ and now can change. It's still usable but no longer recommended.
The vendorIdentifier hasn't changed, but it's not recommended for Enterprise Apps because it can change when updating the App.
The new advertisingIdentifier API is the way to go for new Apps. It's the same for all Apps and should not change frequently, but the user can reset it in the settings page.
Edit: Website udid.io obtains the real Device UDID instead of the obfuscated one if you need it for anything outside your App. If you need the UDID from within the App, see my answer above.
You can get a Unique UDID via this method using private api. Follow this link
Look for the code in accepted answer.
Sorry, but Apple warned it would be deprecated and it has been. I've had the same headache myself.
I can't help you identify the device in the same way Apple do, but you can always generate an unique UUID on app launch and stash that away in KeyChain. It won't be perfect, but it will persist between installations and will be unique to the device. As far as I know, that's the current solution