Does using (for example) UIWebView's subviews count as using undocumented APIs? There is no documentation on the fact that the first subview of a UIWebView is a UIScrollView. Does that mean that I am not allowed to add children to this UISCrollView?
I'm not using any private calls, but it isn't documented anywhere. In iOS 3.1 the first subview of a UIWebView is an instance of a class called "UIScroller", which is almost identical to the UIScrollView, but not documented anywhere. What is allowed exactly?
From UIView Class Reference
For complex views declared in UIKit
and other system frameworks, any
subviews of the view are generally
considered private and subject to
change at any time. Therefore, you
should not attempt to retrieve or
modify subviews for these types of
system-supplied views. If you do, your
code may break during a future system
update.
From App Store Review Guidelines:
Apps that do not use system provided
items, such as buttons and icons,
correctly and as described in the
Apple iOS Human Interface Guidelines
may be rejected
Taken together, I read these as saying: You can look at the subviews of standard components, but mess with them at your own peril -- things will change with no notice, and you'll have nobody to blame but yourself when they break. Furthermore, if you do modify a standard component in a way that's out of keeping with what Apple designed and users expect, your app will likely be rejected.
Modifying the private subviews of UIWebView seems like a poor plan.
I don't think it counts as using private APIs (correct me if I'm wrong), but I wouldn't recommend it. As you say: "in iOS 3.1" it works that way, but it's not guaranteed to work the same on other versions. It may change with an update and the application will break.
By the way, very few use iOS 3.1, so I would recommend looking at how it works in 4.3.
EDIT: I have never uploaded an app to app store where I've done this, but I can tell you this much: You do not submit any source code to Apple. They run your executable in a tool that will detect if you call any private API methods.
Looping through subviews is allowed. So is adding subviews. They don't even mention this in the guidelines. I can't make any guarantees, since I'm not involved in Apple's review process, but I would be very surprised if they would reject your app for this reason.
If you feel like it would add value to your app I would go ahead and do it. If you submit your app to the app store and get it approved, please come back and leave a comment.
Related
Lets say I don't want to use a UIStoryboard in my app. Apple pitches UIStoryboards hard and they also pitch the ability for UIStoryboards to allow you to create a universal app with ease.
I don't want to do this though. So, without listing my long list of reasons my first question is:
Is it smart/acceptable to remove story boards?
Second. Lets say I want to check stuff like Device type to make decisions about what UI to display? I can find plenty of UIDevice extensions that allow for this with with one limitation. If you use these UIDevice extensions when on a simulator you have no way of knowing what the simulator is simulating. So, testing your app on the simulator is not longer an option.
Finally, lets say I used the Size Class API's that Apple provides to try and make UI Code decisions with out a UIStoryboard. Is there any way to get a reference to these size classes pre view loading? The classes only seem to be on UIView and are not available when making window level decisions on app launch.
Is it smart/acceptable to remove story boards?
Sure. Building your UI either in code or interface builder is really up to you, up to the team, or up to the company. If that's only your question, this thread would be closed as that is opinion-based. In your second question, I don't think that's a question.
As for your last question, I'm attempting to answer this question though I do not fully understand it. Perhaps this would help: https://developer.apple.com/documentation/uikit/uitraitcollection
And autolayout should be the answer to that.
This may seem like an odd question, but I'm in the middle of creating an iOS app, and was wondering if there is a way to, in the future, roll out changes to the app without requiring all of the users to download an update.
I've noticed that Snapchat can do this with their filters - new filters are added regularly, without me updating the app.
I've read into 'Cloud code', something Parse had that apparently let you accomplish this. Obviously that's no longer an option.
Also, do Apple even allow this? Seeing as they need to approve every app before letting it onto the App Store, it would seem like they would need to approve any changes first too.
I've thought of strange things like storing a function in a database, then getting the app to download that function and run it - naturally if I were to now change the function in the database, it would change on all users devices instantly. Just how ridiculous is that idea? Thanks!
Depends on how much flexibility you want.
For example, Spotify does this for UI mainly - backend-driven UI, as they call it. They send a kind of layout from the server and convert it to a real iOS layout, based of a predefined mapping. You can find pretty more details in the Spotify's presentation.
Slides: http://www.slideshare.net/JohnSundell/backenddriven-native-uis
Video (more details): http://www.downvids.net/backend-driven-native-uis-john-sundell-and-diego-cristina-ca--777281.html
So actions can also be divided in similar pieces and abstractions, received from the server and interpreted - sort of scripting is needed. You can't compile and run arbitrary functions on the fly.
Hope it'll give you some ideas you can think of.
See Apple's app store review guidelines: https://developer.apple.com/app-store/review/guidelines/ section 2.4.5 (iv). Apps are not supposed to download code or resources to add functionality or significantly change the app from what Apple sees during the review process. And executable memory isn't even writable by sandboxed apps, which makes downloading compiled functions fairly useless. But downloading Javascript that complies with the above guidelines seems to be allowed.
We are creating an iOS app that does not look like any other app you would find in the app store.
My question is, am I allowed to create custom components such as header bars, tab bars, tables etc. for my app and not get rejected by Apple when publishing the app to the app store?
Months of thought and planning has gone into the UI and flow of the app, so the user experience would be superb, we're just concerned about how apple feels about custom apps/components like these?
Regards
There's nothing inherently wrong with creating an app that's got a completely different look and feel to everything else.
But what I would advise is that you try to use the built-in components as much as possible. In recent versions of iOS Apple have introduced a number of APIs to let you customise their look and feel significantly, and some of the most innovative UIs out there are simple table and collection views that have been hacked to pieces.
This is because Apple's built in components have logged many hundreds of thousands (if not millions) of hours of real-world testing and use, and are thus vastly more stable and field-tested than a totally custom component. Plus, they often have various built in features (such as a scroll view's bounce) that are hard to replicate on your own.
So definitely customise your interface as much as you like, but while you're doing it think about whether you can harness the built-in UIKit classes rather than totally re-inventing the wheel.
More and more custom controls appear for iOS every day. If it is so good as you say, Apple will be happy to accept it. Don't worry.
Also take a look at these cocoacontrols
As said before, Apple will not have a problem with that .. as long as you don't use any private APIs. If you are developing these components on your own, you will have to make sure that these will work in future releases (which is not necessarily a bad point) . This may be a problem with third party components, as they may not be continued (or supported in future releases).
Recently I have get a reject from Apple because a use of a private API. I don't know exactly what is a private API nor an undocumented method. Could someone explain me what is an undocumented method and a private API? I'm really confused with that...
Follow up:
What is exactly the "official documentation"? Can I use some frameworks and classes made by thirds such as the Amazon one?
A private API or undocumented method is any object or method that is not part of the official documentation. In Objective C, and some other languages, it is relatively easy to find the list of methods (messages) that an object supports as well as the objects underlying the framework. (For example, just go into the debugger and look at the view hierarchy. You will likely see several view objects that don't exist in the documentation.) Sometimes you will even see instructions on how to use these methods and objects on the web.
One example that leaps to mind is -UIWindow _autolayoutTrace, I use it all the time when debugging autolayout, but it isn't documented and the leading underscore is a hint that you shouldn't be using it. That's fine for debugging, but if I shipped code that used that method it would be certain to be rejected.
But Apple specifically scans for these undocumented methods as part of the App Store review process and rejects apps that use them. This is because Apple might change how these undocumented methods work at any time. If your app was dependent on one of these hidden classes or methods your app might break when Apple released a new version of the SDK that changed this behavior.
There's a set of functionalities that Apple uses internally but are not publicly available for developers.
Any usage of such APIs will result in a rejection of the application by Apple.
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.