Does Apple allow the usage of sysctl.h within iOS applications?
PS: App Scanner, a third party tool that checks code for possible private-API usage seems to think it's okay.
Note:
There is one more question like this : How can I know if I'm using private frameworks?
With the usual disclaimer that nobody can tell you what a reviewer will do, I can say for sure that there are apps in the store that use sysctl functions.
(Minor point: Simply including a header isn't a problem since symbols there shouldn't be visible in your app unless they're used...it's the things you use that might get flagged rather than what's included.)
Related
Is it possible to create an API inside an iOS app to let 3rd party developers create app add-on that are downloadable for users inside the app?
I could not find any ressources for this topic online.
I think that's going to go against the app store guidelines if your intention is that the 3rd party developers write code, which will be downloaded and executed.
There's something of a grey area between legitimate uses and illegitimate uses of downloaded code:
Legitimate Example 1: Something like Hopscotch where children are creating simple fun shared games. These can be considered user generated content.
Legitimate Example 2: A game which is driven by scripts allows for the run-time downloading of patches to fix bugs in the scripts or even to add new levels. I believe such usages have been rejected occasionally in the past, but are generally accepted these days.
The relevant guideline from the guidelines is (emphasis mine):
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other iOS, watchOS, Mac OS X, or tvOS apps.
And the all-encompassing:
We will reject apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it.
If your idea is to create some sort of app-store within your app-store app, then I would abandon it immediately, because that's going to be way over Apple's line.
That said, you haven't given much detail about your app, so I might have made wrong assumptions about where you're thinking of going.
At first, I will describe my use-case on why I need to add the framework at runtime on iOS.
Let's say I have an app on iOS device. The app requires some 3rd party frameworks to add some external features to it. Now, the features are many. So, the required number of frameworks will be many too. An user may not need lots of features. Just a small set of features. Plus, lots of framework will require a lot of space. The application will be huge in size.
For an example, an user needs only 1 feature. The application provides 100. So, all the other frameworks will definitely be unnecessary.
So, the solution would be to download the frameworks and the necessary files on demand from an online repository, link them on runtime and use them. This would mean the application size would be very small and not bulky with unnecessary stuff.
But does iOS provide that? I have to add an external framework and the necessary files that is not on the app use them on runtime.
Is this possible? Can anyone provide me with some resources on how I can do that?
I have seen some resources on SO and some other sites. The results are not so helpful.
"But does iOS provide that?" - no
"Is this possible?" - partially
"Can anyone provide me with some resources on how I can do that" - unfortunately no
More details: That is certainly not possible out of the box. And it will be firstly a pain in the ass to do achieve what you are trying and (far more important) secondly it will probably not be allowed by Apple. You are not allowed to load new "program code" into the app at runtime. For the simple reason that Apple cannot review what you are about to load. And it would a huge security risk for your users if your backend gets compromised.
What you can do is load resources like images, videos etc. on demand.
You might even be able to come up with some scripting behavior of your app. The server could theoretically deliver code to your app and then your app interprets that code. But that code would not be Swift but some other language that you have to define first. You see where this is going? That is possible while not really doable. And still it might get you rejected anyway.
In particular if you are talking about actual frameworks that include actual binary code is is not possible.
OSX has functionality not available in the iOS SDK, and occasionally I'll find an answer like this one: no route.h on the iPhone SDK, that says "just copy the header file from the Simulator (or OSX) SDK and it'll work fine."
That seems suspect to me on multiple levels, including App Store approval, but then I read something like this from an Apple employee who says "if you're using sys/route.h declarations on iOS for an App Store app, please get in touch with me...", which sounds like tacit approval (or a ruse to catch misbehavior :)
Anyone know where the official line really is, and whether something like this is at all safe to do in production code? I'm particularly interested in lower-level BSD functions and whatnot for portability, as opposed to undocumented Objective-C methods.
I would not regard that comment on the Apple forums as tacit approval. It sounds like they're just trying to decide if some additional BSD APIs should be added for use in iOS apps.
In general, if there isn't an iOS header available for a function, then it's considered a Private API (for example, something under https://developer.apple.com/library/ios/). The official policy on Private APIs is that they're not to be used in apps distributed through the App Store.
Now, you can certainly use them for personal/hobby apps, or apps that you deploy in-house (Enterprise Distribution).
If the APIs you're talking about are APIs that are publically documented for OS X, and you can get them to work for iOS by copying headers, then they're probably part of the Darwin source base. It's very likely that they'll continue to function in future versions of iOS, although that's not guaranteed. Of course, nothing is guaranteed (really), as public APIs get deprecated, too.
Then, there's the issue that not all review checks are automated (I don't work for Apple, but can deduce this from things I've seen get through review). It isn't that unusual for apps to be approved with Private API usage, although if they get popular, Apple frequently pulls those apps from the store within a couple weeks. The review process isn't perfect.
So, my answer is that if you're submitting to the app store, don't expect copying in headers to work.
P.S. If you can tell us specifically which BSD function you're referring to, we might be able to give you a better answer.
P.P.S. The answer you link to about Route.h is from Grant Paul, who writes quite a bit of non-App Store software.
Additional useful information on Private APIs and the App Store
Apple never knows what header files you use - the danger of course is the definition from the copied file is close to, but not exactly, what iOS uses. If this file is important, or a few select files, post a question on Apple's internal forums and you will surely get an answer to such a question. Failing that, burn a DTS incident (you get two a year, I almost never use mine).
I am a developer working on a robotics application for iOS. I do not intend to submit this app to the app store, nor do I have any wish for suggested methods to be apple approved....
I am trying to get bluetooth working, and I think a good place to start is to try modifying the existing apple frameworks. Is it possible for me to modify the frameworks so that when they are built to my iOS device the frameworks will be modified for the app (but not other apps on the same device)?
As a matter of fact, you can!
Objective-C allows you to "swizzle" methods to override their default behavior, and yet still call the original implementation if you want to. You can do this for any number of Objective-C methods, as many times as you want.
If you wish to override behavior that is present in C functions, you will need a little bit more control over the platform. Jailbreaking allows you to use the full power of Jay Freeman's CydiaSubstrate to hook or swizzle both Objective-C methods and C/C++ functions.
While I don't recommend the use of MethodSwizzle per se, the following URL has a good discussion of swizzling http://cocoadev.com/wiki/MethodSwizzling.
But you should really use CydiaSubstrate's MSHookMessageEx and MSHookFunction instead. Especially since you're not submitting anything to the App Store.
Now regarding Bluetooth, I've done extensive work in this field (I developed Celeste, which is a systemwide tweak providing vanilla Bluetooth OBEX support to system apps on iOS). I suggest you look into using something like BTstack, which provides you with access to the bluetooth module from the HCI to RFCOMM levels, and supports things such as SDP and pairing, which you will probably need. It also has the added benefit of not requiring method swizzling, which some people seem to think is some sort of satanic ritual that should be avoided at all costs.
Aside from categories (which extend the functionality of base classes delivered in those frameworks), I don't believe you can "modify" the existing Apple frameworks per se. A better course of action might be to simply create your own framework (or find somebody else's open source, commercial or simply third party framework) and then build that framework into the app that you install onto the iOS devices you want to work with.
While I understand that in order for an iPhone application to be accepted on the App Store, one requirement is that only documented libraries are to be used.
If this is the case, how are certain applications such as "Night Camera" and "Camera Plus" using a camera control that seems to be something other than the one contained within UIImagePickerController?
I have heard of certain cases where a developer has been given "special" access to certain headers that allow for features that would otherwise be impossible if constrained to only using documented libraries. However, given how opaque the application selection process is for the App Store, I would prefer to stick to what is recommended rather than take my chances.
Anyone care to shed some more light on this?
Have you seen this dicussion?
http://blog.airsource.co.uk/index.php/2008/11/11/views-of-uiimagepickercontroller/
and this sample code for a custom picker?
http://www.codza.com/custom-uiimagepickercontroller-camera-view
hope it helps.
You might want to check out a classdump of apple's private framework headers. Run this perl script:
http://arstechnica.com/apple/news/2008/11/dumping-the-iphone-2-2-frameworks.ars
and navigate to the PhotoLibrary directory under PrivateFrameworks. Some of the classes in here look pretty promising for direct camera access.
Using the undocumented API could hurt your chances of passing through the app store, but it's all very subjective - If your product is good, apple will probably let it slide through. I'd recommend making friends with a developer evangelist at Apple.
The UIImagePickerController is a UIViewController subclass that manages a view hierarchy. You are free to play around with the view hierarchy, as those apps are, but it is risky considering that Apple does not document it and could change it on any OS update.
I have not heard of anyone being given special access to libraries, but I have read that there is a minor distinction between undocumented classes and methods and private frameworks. Undocumented classes are a gray area, but private frameworks are definitely not allowed.
The simple explanation is that apps in the store are not supposed to use unsupported APIs, but this is not checked consistently. The apps you mentioned are either using unsupported functions/classes/methods or else are playing with the view hierarchy-- which is itself undocumented even though it can be done with standard APIs.
You could do what they do, and take your chances with it. Just be aware of the risks. Your app might (a) be rejected from the store, (b) be accepted but later booted (this has happened for unsupported API use), (c) be accepted and not booted but break the next time Apple has a new iPhone software update (since unsupported APIs or view hierarchies can change without warning). Or you could get lucky and have none of this happen.