My company is looking to develop an iOS application which would need to make use of private APIs to function - in fact use of such APIs is the entire basis of the program (I'm purposely not revealing details for business reasons).
My question is, is there any chance that if we explained the situation, that Apple would allow an exception for our app to be approved even when using these private APIs? I believe we have a very legitimate reason to request an exception for the functionality we're looking for, so I'd just like some examples of any exceptions that have been made to the private APIs rule with details so that we can have a better idea of what might be expected from Apple. Thanks.
I'll be honest with you: no. If you're looking to put this on the app store, no.
You may wonder how I know this with such certainty: I've worked with carriers that carry the iPhone, and I've worked with very large companies with whom Apple has working relationships (ie, you can actually talk to someone fairly senior at Apple). If Apple won't let carriers use private APIs, they not going to let you do it either. One 'legitimate' private API use might be to put recent call information into a carrier provided account app. Could be pretty useful, right? And the carrier already has this information, so no problem? No. It's a big problem. Apple just won't allow it. You have to get it from elsewhere (ie, via the carrier's own database).
There are no exceptions, and currently apps get statically analysed immediately after submission. If you call a private API your app will almost certainly be instantly rejected automatically by the static analyzer. It won't even go through manual review.
If you're looking to distribute on the app store, there are literally no exceptions now that code gets statically analyzed.
Put it another way: if Apple made an exception for your app they'd have to make an exception for every app. And then your unique selling point wouldn't be so unique any more.
Sorry I can't give you a more positive answer, but I speak from experience!
Its entirely possible, but extremely unlikely. they made an exception for UIGetScreenImage(); but that was because there was a very large number of developers who had filed radars for it.
I would suggest you file high quality radars for enhancement, explaining what you want and why. also maybe consider using a DTS to find out if there is an alternative way, or if they are able to get authorisation for it.
Related
New to AdMob and trying to understand compliance as it relates to providing and deleting collected user data to a user upon request from purely programming standpoint.
In my research, it appears that there is an API for the user to at least delete the data. https://developers.google.com/analytics/devguides/config/userdeletion/v3/ being the most helpful so far though not specifically particularly helpful in code examples. This would probably be accomplished either by the developer using the client ID manually or via the developer's app -> user deletion API.
Assuming one of the two approaches is the proper way the industry is currently handling this, how is this typically handled in Swift (ideally via SwiftUI not UIKit but I can follow along either way)? Please note I am not asking how to set up AdMob in general, or how to use UMP to provide GDPR consent, or what anything related to legal/compliance beyond programming.
If there is some other, more preferred option, please let me know that as well.
Thus far I have researched the differences in client ID and user ID from an end user perspective. Code-wise, I am unsure where to start until understanding which approach to take as dictated by the answers above. I have also looked into exposing the client ID vs various items that might be used as a generic device ID but am unsure how best to obtain this as well.
Thanks!
I have created one static library in iPhone sdk, and I am worried that If I provide code to anyone in which static library is being used, then anyone can use static library. So Is there any way to restrict them by using library until they get license? I am new to licensing any library.
This is a problem you must solve by legal means, not by any technical solution.
Make sure to only give the library to people you trust, and if needed have them sign an agreement not to spread it.
Also ask yourself if it is worth the trouble. Is your code so unique that they can not find it elsewhere, or duplicate it themselves in a few days, using Google and stackoverflow alone?
As said by #PeyloW,
This is a problem you must solve by legal
means, not by any technical solution.
But there are some simple ways to "block the code": You can create a RAR or ZIP archive, encrypted with password, and after they get license, you can tell them the password.
If you want to "Bind" license to a "developer's computer", than you simply need something that you can bind. For example that can be the emulator's UDID.
you can generate a license for emulator's UDID, and only limit emulator development, while allowing unrestricted access for ARM code (on device)
so you can basically check for emulator UDID
check license file
if license file allows that UDID, run
if not then show a message etc
for development purposes, everybody needs emulator, so I guess limiting it is enough for you.
Personally, I would create a new static library, check your code coverage and copy in only the code used by the app consuming it. Or in other words, don't give away more than you need to.
Then, as someone mentioned in the comments, obfuscate the calls. Your library is going to be worthless without documentation if your calls have to be deciphered. Odds are that anyone that has the aptitude of deciphering what your calls mean probably has 80% of a white-room reverse-engineering of your code already done.
You can't really force a license upon your client at the final hour unless they agree to it. So even if you did try to force them to license your library, it might not even be valid to do so with the original agreement intact. I'd do damage control to the extent your time is worth and chalk this up as a learning experience. 5 months from now, you'll probably have that static library re-factored to something better anyway. And next time, you'll work that into your agreement.
If you provide the static library, no one can get back the code.
Do you have reservations in others using your static library also?
I am referring to the issues described in this discussion.
From reading that discussion, it appears at the time it was not possible to securely allow a user to use an IAP product on multiple devices.
No, this hole still exists (I just recently finished another StoreKit implementation myself).
I don't think it's feasible for them to fix it in the near future, especially after they've been using it with the public for an extended period of time. Rolling out a new solution that isn't immediately compatible with what's already been implemented could prove disastrous.
Though I think the common consumer wouldn't possess the knowhow to leverage the hole you're concerned about. The difficulty would be in convincing a business manager that.
I've been looking at various posts of iPhone app submission checklists, to prep for submission to Apple, but they are either not thorough enough or maybe I'm missing something (or not finding the right checklists).
For example UIRequiredDeviceCapabilities seems pretty important, but it doesn't get mentioned much anywhere. Is this kind of thing considered too obvious? What other obvious things should I know?
Thanks.
I think it's because it seems more like a part of the design or development process, deciding what is required - at time of submission you should have that all hammered out and setting those values is more a part of testing than final deployment.
I think some of that is more conditional in nature, meaning a lot of times people don't need to use that particular key unless they want to restrict access to their app based on what device the user has.
This is the one I always went by in the past: http://developer.apple.com/news/ios/appstoretips/
But honestly, the most important ones are:
Make sure all the app meta data is filled out and you aren't using any trademarks/copyrighted items anywhere in your app
Make sure you checked your app for memory leaks and fixed bugs for crashing
Don't use other app names in your keywords
Make sure you have error messages
for network issues (or anything else
that might make a button appear like
it does nothing and would confuse
the user)
Answering my own question here:
"Here are some of the important keys that you might want to add to your application’s Info.plist file specifically for iOS:" (according to iOS programming guide). But from what I can tell only CFBundleIconFiles, and UIRequiredDeviceCapabilities are really required (unless you have no required capabilities in which case leave that one out I guess).
CFBundleIconFiles
*
UIStatusBarStyle
*
UIInterfaceOrientation
*
UIRequiredDeviceCapabilities
*
UIRequiresPersistentWiFi
I understand that apple no longer allows me to send "device data" to third-party services. As a result of this, Flurry and presumably every other analytics company no longer collects OS/hardware version data. However, this data is very valuable to anyone trying to target development toward the people who are actually using the apps.
I can imagine a few different ways to collect this data.
1) Send a custom event indicating the hardware/os version to Flurry. This, of course, is in direct violation of the agreement with Apple. However, I suspect plenty of people are doing this, and just not getting busted. Still, not an ideal solution. Even if Apple didn't notice that we were sending this data, I'd rather not have the possibility of the app getting pulled hanging over my head.
2) Use an analytics package which allows me to collect data on my own server. Localytics is one company which seems to offer this. However, I don't think they offer this with their free plan. Is anyone aware of any free (or cheap) analytics tools which will allow me to send data to my own server?
3) Roll my own solution. This could either be an entire replacement for Flurry, or I could continue to use flurry, but send only the device data to my own server. This is a little clunky. I'd much rather have all my analytics data in one place. And would much rather not have to deal with building my own tool if I don't have to
So, is anyone else collecting device data? Are you using one of the above techniques? Or maybe something different I hadn't thought of?
Hi maybe "Testflight Live" could help you.
As far as I know Testflight is allowed by Apple.
https://testflightapp.com/sdk/live/
I've heard of people using UIWebViews to connect to a webpage with a counter. The counter is incremented each time a page is accessed, and the pages are separated by feature/UIView. This way the developer can tell which features get the most usage.
As far as device data, you most likely are looking at rolling your own tracking mechanism, probably going through a server like Google App Engine that's set up to receive your data.
I made this an answer so I could continue to check back, because I'd like to know some more info as well. I voted up your question and favorited it
Good luck, sir