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.
Related
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 using the solution provided here to open my containing from the share extension. It doesn't seem to use any private API way to do that despite that it is fragile.
Will Apple reject my App if I use it? Anybody has an approved app that open containing app from share extension? If so, what is the right way to do it?
Any pointer is appreciated .
Though there are loads of questions on how to open containing/parent app from share extension, none actually talk whether the proposed solution/hack will be approved by apple or not in detail.
One such example is
Share Extension to open containing app
suggests that Share extensions are not supposed to open the container app.
While browsing some time back, I rather found a very interesting thread discussing the same topic here
https://forums.developer.apple.com/thread/27295
The thread questions, whether the hack of traversing UIResponder chain to open the parent app using openURL will be allowed by apple or not? (Precisely the same idea shown in your posted link as well).
Though the thread again does not provide clear answer as, whether it will be approved by apple or not but points out a very valid concern and warning
The fact that +[UIApplication sharedApplication], and hence -openURL:, is not available to extensions should be an important hint here.Ignoring that restriction and looking up the symbols via the Objective-C runtime is not a good idea.
Clearly, thread suggests (implicitly, by not clearly stating the fact that apple will reject the app with such hack) that though apple will approve the app for now, it will only be a temporary solution.
Now this finally leads to the answer:
Answer:
In a recent apple event held # Bangalore, I had an opportunity to meet the developers of extension team # apple. I told them that I have been using the above mentioned hack to open the app from share extension will this be allowed by apple?
His answer:
`UIResponder`
is not a private entity, hence usage of UIResponder will not violate the private API usage condition hence apps which are using the above hacks are still being approved by apple. But the fact that, your code parses through the UIResponder chain to trigger the openURL is very costly and not suggested/preferred.As Apple seems to be aware of developer using it, they might start rejecting the app in future. (Must say, he wasn't sure of the last point, apple rejecting app in future hence highlighting might)
He also happened to mention about usage of WebView to open the app which developers used quite sometime back as well. Which is no longer working.
Conclusion:
Yes you can submit the app which opens the parent app from extension using above hack but being completely aware of the fact that this is only a temporary solution and apple expects you to write completely independent share extensions
Question is Answered for current iOS version of iOS11. The answer might lose its validity with future releases of iOS
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.
I want my app to make urgent security updates without going through Apple's review process. I am not trying to do this for all my updates, or circumvent Apple's reasonable review requirements. All it would have to do is push a .swift file to the client, which would be accessed somewhere in the app.
I definitely know there is a way to do it in JavaScript, as I already made a mechanism of the same type in a React Native. I used this approach, but I don't think there is an equivalent for iOS from what I've heard.
There definitely is a solution, as I've heard many devs doing this (for less, um... valid reasons) but I can't find it.
You cannot do this, for both technical and policy reasons. Apple expressly forbids you from delivering new code to your apps's outside of the app store process.
The other part of it is that your apps run compiled object code, not source code. Aside from the iPad Swift playgrounds app, there is no Swift compiler on the user's devices.
Javascript is a horse of a different color. That's an interpreted language, and is designed to be delivered and run dynamically.
I'm submitting an app to the Mac App Store and this app uses the Safari component to display web pages. I'm being asked this question:
Is your app designed to use cryptography or does it contain or incorporate cryptography? (Select Yes even if your app is only utilizing the encryption available in iOS or OS X.)
Should I answer yes due to the possibility of HTTPS?
The answer is a resounding yes. I talked to Apple representatives and they confirmed the need of an ERN if you just use standard SSL in the form of HTTPS. There are many blog posts and forums out there saying that you can just say no and everything is fine, but I don't believe they are following the rules, they are just not being caught at an audit might find their applications pulled from the app store. For those arriving here hopping the answer was no, I'm sorry.
But there's hope. I actually got an ERN and I described all the nitty gritty details so you can do it too with the minimum of pain in my blog post: How to legally submit an app to Apple’s App Store when it uses encryption (or how to obtain an ERN)