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).
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.
Hello I am building forms over and over in iPhone and iPad apps:
Custom UITableViewCells for labels with input
Localization for labels, placeholder text and section headers
Validation that marks the cells red or something and does not allow "Submit" if form is incomplete
Clicking in the cell activates the editable text box
Next / previous buttons
Reliable across devices, orientations, iOS versions
I can't imagine I'm the only one doing this. Is there a mature framework or something that can drop in and use? Could you please comment on how you use this library with designs other than vanilla UITableViews with your own colors etc.?
Take a look at IBAForms - an open source project from from Itty Bitty Apps. I haven't used it yet myself, however I believe it does most of what you want, except for validation. Here is the github page: IBA Forms
It hasn't been maintained in a while, but if you're looking for a forms library - it's mature and works. At the very least, it could be the starting point for something you take further.
Update: There is also Chris Miles' EZForm library, which is very nice.
Update #2: Have also started checking out QuickDialog, which seems to be very popular.
Update #3: Nick Lockwood has created one called FXForms
Update #4: Martin Barreto has created one called XLForm
I don't know if this counts as an answer, but i use Sensible Cocoa - Sensible TableView (STV) for this purpose a lot. It's not a "forms" framework (on top of UITableView) as such, but it can be used for this purpose in a very flexible way. It still requires some coding to build a full-fledged form but the UITableView/UITableViewController boilerplate code is reduced to a minimum. Unfortunately the developers bumped the price tag quite high with version 3.0, so i'm actually looking for a STV replacement right now. (I'd stick with STV if it wasn't for the price!)
I don't know of anything that combines all those features, but I recently open-sourced my validation library PMValidation on github, which I used developing the iPhone app Imprints. PMValidation comes with many basic types suitable for validating forms, and in fact that's what I originally built it for.
Using the PMValidationManager class you can easily listen to UITextViews or UITextFields, and update whatever graphical widgets you want via notifications. It's very modular and easily extendable, should you have more unique needs. It's under the MIT license.
I have a pretty much standard UITableView, but I would like to change it to look like what would be considered a normal table outside iOS development -- make it have more columns (but just one row) and make the cells square-shaped.
I thought about making more tables (one for every cell) and then placing them next to each other, but that wouldn't be so convenient.
Is there maybe a simple way to make cells go on the right of the one before instead of going below?
Use some third-party classes that allows you to have "Grid Views".
One is my OHGridView class, another is NRGridView, and there are many more. If your app needs to be compatible with iOS4 and/or iOS5, using a third party class (or building one yourself) is the only option.
Under iOS6, there will be some other stuff that allow you to do that directly (iOS6 still under NDA so we can't talk about it publicly yet, but go read the API Diff files in the developer.apple.com website if you have access to them). So if your app is intended to be compatible only starting iOS6+ and you don't need support for iOS5, this could be the solution and you should go read about it if you have a developer account with access to the iPs6 SDK.
What you're looking for us UICollectionView.
I was looking into creating iOS-apps (especially for the iPad) with the Adobe-Flex framework. It looks very promising to code apps this way.
Is it possible to create own controls/widgets? In the far future I might want to create my own kind of gantt-calender or whatever. Is something like this possible and are there any good tutorials/book out there?
Thanks in advance!
UPDATE: I want to create iOS Components that I can use in Flex. Controls, that are not aviable by default in Flex. Is that possible? By derivating or something?
UPDATE 2: In the meanwhile I found FlexLib to be useful. How hard is it to create stuff like this on your own? Especially for mobile devices. Are there any good tutorials, books, etc. out there?
Yes, you can create your own Controls in Flex. They are commonly called Components. I suggest you start by reading the Flex Docs on how to do so. There are also plenty of other resources out there. One is a screencast series that I created for The Flex Show. Here is episode 1.
You had asked:
How hard is it to create stuff like this on your own?
It depends on what the component wants to do. The commercial components we've built at www.flextras.com have taken from three to twelve months to build. Our Calendar is built from scratch, but most of the other components extend existing Flex Framework components.
The Flextras stuff are architected for reuse. A "single use" component for a specific app can be built in 1 hour [and up].
Once again, the purpose of a component will affect how long it takes to build.
#chiffre
Ok, maybe I am guessing wrong but "iOS controls" makes me think not to "flex controls".
Anyway with Flex 4.5.1 you can add any controls you want, the only thing that you must count (and this counts a lot) is performance.
Read especially about item renderers since scrolling list is not so fast on iOS and how you can make use of cacheAsBitmap.
Also keep in mind to always use light controls when needed if not extend base controls like UIComponent or Sprite and not Button if you just need a rectangle.
Here are some links
http://blogs.adobe.com/flashplayer/2011/06/adobe-air-2-7-now-available-ios-apps-4x-faster.html
http://www.adobe.com/devnet/flex/articles/mobile-development-flex-flashbuilder.
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.