I have an iPhone app and would like to create iPad version of it. What is the best way to setup the project when you want an iPhone and iPad version of the app?
I don't see that I'm able to use the same code base since the iPad version will have features in it that the iPhone version doesn't. It seems as though maintenance is going to go up with two similar code bases for the same app.
Refactor the common portions out and create a new target. You're the only one who really knows what the best way to do that is.
I just went through this thought process this week myself, having a published iPad app which I wanted to create an iPhone version of, and I decided on using the universal app approach. I found it worked extremely well for my needs. Once you get past the project setup issues, and the tactics of design decisions of where and how you are going to split up your iPad/iPhone specific code, the universal app framework is pretty fabulous.
Along the way, I created a reusable universal app project template, which I then used as the starting point for my universal app. The code is open source, hosted on github, I encourage you to take a look at it as one way to approach your problem, knowing that it is a tested solution that worked for me. (Additionally, I welcome any contributions from anyone wanting to help make it a more useful project)
The github link is: http://github.com/ryanscott/rcloudlib/tree/master/Samples/rcuniversaltemplate/
In terms of maintenance, I am extremely happy with the minimal added work it takes to support both devices. Sure, it's more work than supporting just one or the other, but it is significantly less maintenance than two separate codebases, where the business & app logic is almost identical.
In summary: I strongly believe that using a universal app is the best approach to creating an app that runs on on both the iPad and the iPhone.
Since the features should be similar but the layout is separate, code base s/b ok but the ib should change - making things far simpler; now v4.0 is a different answer :)
Maintenance would go up a bit. But if you have your app written abstractly enough, it should be fairly easy to port it to other devices. (For example, if you never assume that you will always know the screen size, you should be able to change that fairly easily).
For other things, it may be a bit difficult. However, if you use the Model View Controller (MVC) paradigm of thinking, you should be able to develop both apps simultaneously with only about 1/3 of the extra work. (Keeping the same model and controller, and only swapping out the view, alternatively, you could include the controller in there, but I wouldn't).
Related
I'm an experienced C/C++ Windows developer writing my first real iOS application. Since I don't really have to worry about backward compatibility, I decided to jump in and use the new Storyboard functionality in XCode 4.3. What I'm finding is that, while storyboarding holds out the promise of laying out all the screens in your application including segues and gestures without writing any code, the reality is that anything but the most trivial of programs don't work when you run them, usually failing unceremoniously with a very unhelpful error message. Worse yet, you can't step through the code to see what is wrong, because there is no code.
So my question is this: Should a new iOS developer develop without Interface Builder and Nibs and Storyboards at first as suggested by this article?
UPDATE 2020-04-03:
It looks like SwiftUI bridges this chasm nicely and will probably be the way to build iOS apps going forward. In SwiftUI you do have code to step through, and it gives you real time feedback in Xcode showing how your app will look when it is run. As of this writing, there is a great free 100 day course (no affiliation) that I've been enjoying which includes an intro to Swift. Recommended.
Yes! You should definitely use Storyboards to build your applications. One of the neat things about Interface Builder is that it doesn't abstract away the underlying concepts - you are still working with the same types of objects as you would in code (UIViewController, UIView, etc.).
This lets you still learn how UIKit works but experience the benefits of building your UI using a tool.
There is a WWDC presentation from last year that outlines the basics of using Storyboards in your apps:
https://developer.apple.com/videos/wwdc/2011/?id=309
This is quite subjective but I definitively agree. If you want to learn how iOS works definitively start the UI code first. Interface builder is useful to position elements quickly and accurately, but like the article mentions you'll be much more productive after you understand how the views and controllers work together.
As a beginning developer I'm wondering what the pros and cons are of using Storyboard vs. .nib files to build app interfaces.
I'm aware that:
Storyboards supposedly streamline the process of creating interfaces
Apps created with storyboards are not compatible with devices running pre-iOS 5
However, I'd like to ask people with experience what the unforeseen drawbacks or advantages may be to using one method over the other, and what experienced developers recommend starting out on. (I'll be developing both for personal and commercial use.)
Thank you very much!
Just starting out, I would stick with Storyboards till you are comfortable with iOS's style of Model-View-Controller.
Once you are more experienced, be sure to play around with individual nibs because you still might need to use them in conjunction with a Storyboard for things like PopOvers on an iPad.
The only drawback I've found with Storyboards are when you use them in a team setting. Only one person can ever be working on it at a time, because no version control software I've found merges conflicted Storyboard (I've tried SVN & Git) well and you usually end up with a broken Storyboard.
Personally, I find storyboards much easier to use than nibs. Especially because segues take out a lot of silly repetitive code to change view. Then there's the whole pointing out the obvious that it makes it a lot easier to get an overview of what your app looks like view-by-view all in one screen.
In all my developing so far, other than incompatibly with pre-iOS 5, I've found no drawbacks with storyboarding.
I have developed an app for the Android and it's working well, finally, and thanks to all the help from StackOverflow!!
Now I am being asked to make it work on the iPhone. I looked at iPhone a while ago but not recently.
What does everyone think? Should I take the time to learn Objective C and iPhone and port the app or forget it?
Are there any books that cross-reference functions so that you can look up how to do something in iPhone that you already have on Android?
From my experience in school, if you have already been able to create a working smartphone app in at least one mobile OS such as android, it wont take long before you can understand objective C and cocoa framework stuff. The only problem with that is you may probably need an apple developer license to use XCode.
So, I would say go for it since you also get paid, and also here is a link to iphone development guide for android developers : http://integratingstuff.com/2011/02/27/starting-iphone-development-as-an-android-developer/
Probably, it's better to get a partner who develop to iOS than doing it yourself.
Focus on a platform and let your products run to all users.
Unless you are using a framework that supports both iOS and Android (something like the Corona SDK) you won't have much actual code that will transfer over. Ideas, algorithms, logic, graphics, designs, etc will all transfer over just fine. Those are the hardest parts (IMO) of software dev.
Objective C (the language iOS apps are written in) is not that hard of a language to learn if you already know C-based languages (like Java). There are a few concepts that are different, but for the most part, it's not that bad. The biggest challenge for developing on iOS is buying a Mac. You can program for Android on Windows or Linux boxes, but iOS apps can only be developed on an Apple. Unless there is something that has happened in the Hacintosh arena that allows for iOS development on other platforms, you're stuck buying new hardware. BUT if you already have a Mac, download XCode and go to town!
Like Haphazard said, if there is enough money in it to make it worth your time, do it.
If you are getting paid, go for it! (Also, it could be a great learning experience.)
When I had to make the same decision, I considered the following criteria:
how much money is in the app on the other platform ?
how many times will this happen in the future, or is this going to be the only app? (how big is the benefit of learning the other platform for the future)
how much insider know-how is in the app that one is willing to reveal to another programmer porting this app (in my case I do mostly device handling apps, which is not really all that common)
what is the opportunity cost of spending time on porting an app instead of developing another profitable on the initial platform
If you have any possibility, you may look into similar apps and see how they are doing on the two platforms...
Good luck, whatever you are going to do...
I just learned about this and have not tested it yet, but one thing that you could do depending on the app you have you could take a look at PhoneGap. It looks pretty promising, though it may not work for your case with your initial application already made. But in the future this could help.
Unfortunately you will either have to re-write the app from scratch for iOS, or hand over the job to an experienced iOS developer. You can fairly easily port over the logic and computations in your app from Java to Objective C, but the user interface is the area where you cannot really re-use anything (except maybe icons), and the user interface tends to be a large portion of most apps.
As an Android developer who has ported several of my apps to iOS, I can say that this transition is a hard one. Firstly, you need to buy an iPhone and a Mac (if you don't already have these), since you cannot develop apps for iOS without the Apple hardware. Secondly, you need to learn how to use XCode and Objective C or Swift. And thirdly, since XCode ONLY allows creating the user interface graphically (as opposed to Android which lets you hand-edit the XML), there are many hidden things which can cause you to come unstuck. (UPDATE: Using the new SwiftUI approach to user interface design really helps with this last point, and in my opinion makes the transition from Android to iOS easier).
Finally the Apple and XCode environments seem rather alien to someone who is used to Windows and Android Studio. There are things like the Home and End keys having completely different behaviors to Windows which is frustrating. Also you have to use a combination of key shortcuts and mouse movements to hook up user interface elements to your code. Also, there are big annoyances such as the pop-up keyboard on iOS not pushing the content out of the way automatically like it does with Android. This is probably because Android is an OS designed for multiple screen sizes, whereas iOS is design for a limited number of screen configurations, but it makes iOS feel inferior and harder to work with from a developers point of view. (UPDATE: Using a ScrollView in SwiftUI solves the keyboard obscuring problem).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to build a mobile/tablet application whose core feature will be taking pictures with the camera , viewing pictures and receiving notifications. Also I want to target iphone, ipad and android platforms.
Titanium appcelerator piqued my interest because of its cross platform appeal. However I am concerned because I've read mixed reviews on SO and other sites. The things that worry me are:
Subpar android support
Camera support not fully capable (e.g ios 4.1 HDR capability)
Camera support buggy
The nightmare scenario for me would be to invest time in titanium only to discover later on that its a major PITA and drop it and go "native"
Please share your thoughts and experiences.
I chose Titanium for a serious application, although one that does not use the camera. I think there are a variety of things that could play into your decision...
If your app intends to do "fancy" stuff with the camera, or some real heavy image processing and so on, you're likely better off going native. If on the other hand, you just want to have it take pictures, and then those will be used as-is, or sent to a server, or what not, then Titanium should work just fine. Titanium does have some processing and image manipulation things, but as others have said, if you really want to take advantage of the device's hardware, you probably want to go full native.
It should also be noted, and Appcelerator says this as well, that with a Titanium app, you won't just write a single app that works as-is on all devices. You will need to taylor the UI to each device (or class of device, i.e. iPhone, Android), because they have different UI's, and different standard UI flows and so on.
But, one of the potential advantages to Titanium is if you don't know Objective-C and/or Java, and you do know JavaScript (and in my case, I'm actually using Coffeescript :). Or, if you would enjoy your work much more writing JS than ObjC/Java. This was one of the main reasons for me. I have done some ObjC dev in the past, and don't even mind it, but this project I'm doing is on a very very aggressive schedule, and it was just going to be far more effective for me to use Titanium. I was able to get set up and build an app extremely quickly, and I am not spending any time having to become more deeply familiar with the programming language I'm using, memory management bits (you can't fully ignore this with Titanium, but essentially they're doing it for you). Based on the folks I've talked to, and how much time they spend with memory management, Interface Builder issues (this is mostly the ease of forgetting to setup connections or hook various things up, IB is actually a pretty great tool), and so on, I'm quite glad I'm using Titanium.
While I expect to do an Android version at some point, it's not a priority. But, I'm glad to know that a large chunk of my app code will be re-usable, tested, etc. and that I'll wind up mostly just building/revamping the UI for Android, not rewriting networking code, data management, and so on. Android support will be much better (supposedly) in Titanium 1.5, but you may want to wait for that release to evaluate Android if that's a priority.
Finally, Titanium does have a "module" system, that allows you to wrap native code, exposing it as a JavaScript interface in Titanium. We are about to leverage this to integrate a third party library, and at least for what we need, it looks very easy to use, and has given me a little more confidence that if some particular native feature we need access to comes up, that we'd have a decent chance of integrating that while still using Titanium, but I think it would depend on what the particular native functionality was.
Good luck and enjoy building a mobile app, it's pretty fun!
We have been using Titanium in one of our projects for around 2 months, and frankly speaking our experience with Titanium is too bad.
As per my opinion, below are some major drawbacks of Titanium:
1) First thing is you will not get debugging support at all (We can understand how debugging require in any of the project and in any of the technologies).
2) Titanium is NOT fully supporting all the features of Android/iPhone; beyond some level it will not give you support.
3) Comparing with Android/iPhone SDK, developers will get very less amount of help from the internet and API library (Titanium provides the API library help file).
These are the general issues that end developers face while dealing with Titanium and I suppose sometimes it will be tedious and frustrating work for them.
If the functionality of your application is somewhat like displaying data from the web (like many news, media type apps) then Titanium is the suitable option; otherwise not.
The Android support is not near as good as it is for the iPhone. If you were to just say iPhone I would say you would have luck using Titanium. However, I think trying to build one code base in Appcelerator and also use in your Android environment may not be the best experience.
That said, IMO doing Android / Java code is much easier than doing Objective C / iPhone work.
So worst case I would consider using Titanium for your iPhone version & do Android in Java.
You can give it a shot doing them both in Titanium, but worst case code the Java version.
I just hate objective C and the 'native' Apple development environment so much.
I would recommend against using a cross-platform toolkit when interacting with device hardware is one of the key requirements of your application. I haven't worked with Titanium before, but I find it hard to believe that they will give you the same level of hardware access that you get with native frameworks.
In particular, iOS 4.0 added a mess of new capabilities regarding the camera, including live video frame processing through AVFoundation, and I find it hard to believe that a third-party framework will keep up as these platforms advance. To be honest, it's pretty easy to write an application that interacts with the camera on the iPhone nowadays (count the number of them on the App Store as an indicator of this). I wrote a live camera frame processing application in about six hours the other day.
I can't speak for Android, but I imagine dealing with cameras is fairly trivial using the native APIs there as well.
You're also going to find performance testing and debugging your application to be far easier using the native tools than those supplied through a third party. In particular, Apple's Instruments is an extremely powerful, yet easy to work with, application for tracking down CPU and memory issues within your application.
There's also the community aspect. You'll find far, far more people working on Android and Cocoa Touch than on Titanium (just look at the numbers of questions in the various tags on Stack Overflow to see that). This means many more tutorials and a whole lot more sample code that you can use.
The time you'll spend getting your iPhone and Android build environments set up, and submitting to both stores, will be the same no matter if you go with a native environment or with Titanium.
In the end, even with learning both platforms, I think you'll come out ahead by avoiding a cross-platform solution. Trust me, I've tried to do cross-platform development before for other projects and ended up with lowest-common-denominator products that took much longer to write.
I've developed an Appcelerator-based camera application and was very pleased with it. I think some of the negative reviews come from the fact that it's a bit hard to get set up (more due to Apple's crazy developer registration process).
Once I got started, it was easy to do things like overlays on top of the camera screen. I was really expecting difficulty with that part, but it worked well.
I have spoken with the Appcelerator team in the past, and they are a great group to work with. I've seen them be responsive to other user issues, and I'd trust that if I ran across a real bug, they would address it quickly.
A little late, but my two cents...
I honestly believe you can very quickly prototype an application with Titanium Appcelerator and focus on the critical feature sets to determine if it is the appropriate tool for you.
All developers have there opinions and experience(s) which influence there comments; developers have different ways of learning and different levels of productivity... In the end, it comes down to how are you most productive with the tools available to you.
Since you are stating from the start that you want to deliver a solution an multiple platforms, I think it would be a poor decision on your part to not even spend a week or two investigating cross-platform frameworks and then making the decision based on your personal experience.
There is Titanium Appcelerator and there is also PhoneGap, where PhoneGap might help you is that there is the ability to extend/enhance the underlying framework through writing plugins (I wrote one for iphone ) and there is an android one on my blog also... this can fill missing gaps for you when you move across platforms.
Also since the UI in a phone gap solution is HTML5 Webkit based, it can give you a consistent look and feel across you devices if you like. Frameworks like jQTouch and JQuery Mobile are being used for UX with PhoneGap Application
I reviewed negative feedback for Titanium Appcelerator but I tottaly agree with Aaron Saunders that if you use PhongeGap Development is support HTML5 which can getting easy to make apps for iPhone, iPad and Android mobile.
Has anyone highlighted the cost off titanium.
I was contacted by them today and if you are more than a one man band you have to sign up for a partnership program else you are held liable for breech of contract if you release the app.
The partnership program is £5000 which is far to much for us as a start up company when it's our first application, we are currently looking for a different option now.
I believe a lot of people have heard of and even used three20 library for building their apps. What's the pros and cons of using it? what's your experience so far - starting from ramping up, app design, building, to approval, and future maintains...
I am interested in picking it up, attracted by the UI elements that not easily get from the official SDK.
I've started developing a new app with Three20. Little note: I've started iPhone Development about one year ago.
I was attracted by the UI elements too, so i thought I'll give it a try.
Downloading the source is strait forward, but when it comes to integrating Three20 to an App it gets difficult. I think I've need about half a day to get it running. The big problem was, that I'm using XCode 3.2.3 with iOS SDK 4.0 and the source I've downloaded was set to run on iOS 3.2. After I read a lot of blog-posts and stuff like that, I finaly managed to run my app on the Simulator and on Device.
The next steps were kind of easy. You can use the UI-Elements and Core-Functions of Three20 easily. Build your app using the URL-based-navigation is great. So Three20 does at lot of things you normaly have to care of yourself. E.g. normaly you have to alloc and init your ViewController, push it to your NavigationController and release it. In Three20 you only have to "call a URL" and the rest is done by the library.
From this point of view Three20 is really great. The next problems I faced was, when you want to customize or change the standard-build-in-components. I've spend a lot of time reading through the class documentation on Three20.info until I've managed to build my own TableCell. I've faced the same Problem, when I want to load my data a different way to a TableView.
Until now I haven't got any problems with some other libraries in the same project.
I think Three20 is great and easy. On the other side it can be quite difficult. If you like the UI Elements, you should give it a try.
The main problem with Three20 is you have to take all of it or none of it - you can't easily just choose a part you'd like to use.
It's worth searching out other projects that do things you might want Three20 for - like photo browsing.
I used it for a few time. The main con is that you must develop the entire project with the three20 library else some bugs will appear.
I inherited a project that had Three20 integrated just for the networking and the message controller. I don't like it. If you just use the functionality it provides, it works, but when you want to modify something you find yourself drowning in spaghetti code. You also discover a lot of bad coding practices – my favorite was a BOOL value being cast to an object pointer. Some of it looks like it was ported from Javascript. I set an intern to work finding all the parts we don't ever call and commenting out as much Three20 code as possible, and at least I no longer drown in compiler warnings. Now we're spending the time to write our own message controller, and I am looking for a different networking stack.