I understand that iOS 5 is the latest (and the greatest) version of the Apple Mobile OS. I also know that it contains ARC, OpenGL ES Debugger yada yada yada...
I have already developed some in-house apps at my company and they all work perfectly fine. But as a developer, should I really bother upgrading all my apps to be iOS-5 compatible? If so, why?
"Upgrading" doesn't really apply to apps, only the OS. If your app already runs fine on iOS 5 (ie is "compatible"), which it might well be, there's no reason to change it.
If it's not currently "compatible", implying that you've tested it and something in the app is broken when run on iOS 5, then you would consider fixing or working around those issues so that your users on iOS 5 can use your app.
If these apps are ones that you're continuing to develop, you'd consider whether using the new technologies (ARC, new frameworks, etc) is worth the trouble of doing so and/or dropping support for older devices. That's a tradeoff only you can make relative to your apps and your business needs.
Considering that majority of crash related problems are due to memory allocation/deallocation/reference errors, it might be helpful to port the code over to use ARC. Of course the time/cost will need to be determined to see if it's worth it.
Do a cost benefit analysis.
Would an update building with the iOS 5 SDK benefit your customers by fixing existing or probable bugs, adding iOS 5 features, or providing other opportunities to just make a better product? Would an update provide you or your company with an additional marketing opportunity? At what cost in development, test and QA time?
Perhaps it would be a long term advantage in helping keep your development skills more up to date on the new APIs and tools (such as ARC).
But there's also an adage: If it ain't broken, don't "fix" it.
Related
I have several iOS enterprise apps that had been developed years ago, and some of the earlier ones contain elements that Apple has deprecated, such as UIWebView.
My question is, after Apple has stopped supporting deprecated elements, will these elements continue to work in existing applications? Or will I need to go in and update the deprecated elements in all the apps in order to maintain functionality?
When Apple deprecates an API, it means that they intend to stop supporting that API in the future.
Sometimes this is because the API is no longer useful or is flawed (creates a security hole, for example), but it's typically because it has been superseded by a superior API and Apple is encouraging you to adopt the new API.
Existing applications running on existing operating systems will, naturally, continue to function.
When Apple is replacing one API with another they will typically maintain the legacy (deprecated) API for as long as practical. So your app is likely to run on at least the next few major versions of the operating system.
Apple also tries to avoid forcing you to choose a new API because that complicates development since you now have to support two APIs in your application if you want it to be compatible with earlier versions of the OS. (Of course, if you want the features of the new API today, you don't have many choices: either support both APIs or limit the OS versions your app can run on.)
How long is on a case-by-case basis. A security flawed API might be removed in the next OS. On the other end of the scale you have string encoding APIs that have been deprecated for almost a decade (because they can't properly handle all Unicode conversion cases), yet they are still included in the framework and still function as advertised.
On high-profile classes like UIWebView, I would expect it to continue to work for years to come, but it won't be improved or get any of the new features of WKWebView. So, over time, it will look and act more and more dated. How important that is to your app is a subjective decision for your development.
I believe it depends on the user's OS version on their device. If the OS no longer supports the deprecated elements, then you may notice an error similar to the one below:
"[Appname] needs to be updated"
I would like to start off by saying that I am a novice programmer. I have only learned Java and Android studio, and I know very little about cmd prompts and that sort of thing. I recently found j2objc which can roughly translate my java code to objective c, and hopefully make it easier for me to transfer my app to ios. I also know there is a gradle version. For some reason, there is no "tutorial" on youtube about setting up any type of j2objc. My Android studio project is on my Windows 8 desktop and my IOS xcode app is on a VM running IOS 10.13. Can anyone help me get this working? (I may need you to explain things to me like I'm 5).
I'm sorry, but as the project lead for j2objc, I don't recommend you use it. j2objc has more benefit as the amount of shared client-side grows, so smaller apps go through a lot of pain for very little benefit. Our most successful client apps tend to be huge (think Gmail, or the Google Docs apps), written by large teams of engineers.
What I encourage is that you initially focus on sharing code on the server-side, with your apps providing the user interface but doing very little calculation on the client. If profiling your app shows it is slow due to network accesses, then you might consider caching or some other local code. If you keep all the interesting/changing features on the server-side, then small, lightweight clients require much less work even if they are rewritten for each new platform your team supports.
We currently have a .NET SaaS web app with individual deployments per customer. We are on a monthly release schedule and each customer is upgraded to current releases on independent schedules. Sometimes a certain member might even skip an entire release, upgrading on the subsequent release.
We are looking to develop a native iOS application and are trying to figure out the best way to keep a single iOS codebase in sync with multiple supported server-side deployments. I know that Citrix ran into this with GoToMeeting because at one point there were multiple versions of their native app in the App Store to satisfy customers with a variety of server-side versions. Supporting multiple releases corresponding to currently supported server-side deployments in the App Store is not an option we are considering. We have discussed having conditional branches in the code to check which version of the server-side code the customer is using and disabling more current code and features for those users, but this isn't ideal either. Certainly others (such as Citrix) have run into this and have come up with cleaner solutions so I thought I'd cast my net and see what responses I could get. Any help or suggestions greatly appreciated.
Thanks.
When dealing with differences in API versions I would think a configuration file on your iOS app is essential. By configuration file I mean a plist or just settings download that fires when the app runs and tells it where to go for api's. This lets you do what you need with other api versions and when you are ready you can just change the configuration and point it at new versions.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We want to develop an application for iOS and Android smartphones. We are mainly using Microsoft technologies for developing our applications. We thought that if we would use MonoTouch and Mono for Android we would only have to maintain one code base with only a different UI layer for each device.
Because currently nobody in our small team ever developed a smartphone application and we need it quickly we want to outsource it. We asked other companies whether they perfer MonoTouch or Objective C for iPhone development. Most of them said, that the would choose Objective C. They said that Objective C offers more functionality and possibilities, it's faster and for MonoTouch there is a chance that Apple will not support it anymore in the future. Is all of that true or are there other reasons to prefer Objective C? I know there are other threads like this around, but they did not answer my questions, especially the one regarding Apple's support for MonoTouch.
applications. We thought that if we would use MonoTouch and Mono for
Android we would only have to maintain one code base with only a
different UI layer for each device.
this is a possibility IF you structure your app right. If not: no.
If you use Java+ObjC+C# (for WP7 / Win8 metro etc) then this is not an option AT ALL
Because currently nobody in our
small team ever developed a smartphone application and we need it
quickly we want to outsource it. We asked other companies whether they
perfer MonoTouch or Objective C for iPhone development. Most of them
said, that the would choose Objective C.
If you are outsourcing it, you should dictate what you want it written in, surely? If you need to support it in-house, and you only have C# skills, then MonoTouch etc makes more sense for you, the people paying the bills!
They said that Objective C
offers more functionality and possibilities,
FUD, and also incorrect. Monotouch has the full API available. If it's not there, as Xamarin to bind it (which they have done often before)
it's faster
I'd love to see the benchmark. Yes, technically, it can be faster in some circumstances, but in general use, MonoTouch the same or quicker.
Programmer error is a more common cause of iOS app performance problems. eg not getting things off the UI thread (which is easier to do in MonoTouch than in ObjC, tho blocks have helped that a lot), or taking too long to get out of FinishedLaunching (the "main" method, if you will, tho it's not really...)
Garbage collection and things like linq, xml/json parsing, generics and collections are also hugely valuable, and very quick.
and for
MonoTouch there is a chance that Apple will not support it anymore in
the future.
yes, there is a chance. There is also a chance that Tim Cook will run off with Apple's billions and buy all of Hawaii (rather than Larry Ellison's "I'll just have this island" purchase). But the chances are now rather slim.
Is all of that true or are there other reasons to prefer
Objective C? I know there are other threads like this around, but they
did not answer my questions, especially the one regarding Apple's
support for MonoTouch.
Apple doesn't support MonoTouch. Xamarin does, and they do it exceptionally well. Apple doesn't support anything except XCode, which is their product.
Apple DOES allow MonoTouch apps (there are lots). Another way to look at it: usually, 95% of the top 100 games are written using Unity3D, which is based on the same techniques (ahead-of-time compilation of C# code and embedding a cutdown version of the Mono/.NET framework).
There ARE reasons to prefer ObjC which would be:
You already know ObjC and CocoaTouch and like it.
Your team already knows ObjC and CocoaTouch or you can easily hire people who do (note: currently, as far as I know, iOS developers are CRAZY expensive to hire, if you can get them)
You need to use the beta's the day they come out. Keep in mind that you can use the current MonoTouch and deploy to your iOS[REDACTED] device with the beta on it. You just can't use the new stuff in iOS6 YET (Xamarin said "around 2 weeks" which should be about now...). Also keep in mind that you can not deploy an app to the store which is built with the beta SDK, even if you don't use any of the stuff in it. You can't even mention iOS[REDACTED] in your product description (I've tried)
you love [squareBrackets andTheOccasional:#"strange syntax things"];
Now, will building a cross platform, shared code app be an easy undertaking? HELL NO. It's a very complex piece of development for a non-trivial application. But thats the fun part of software development: if it was easy, it'd be boring! Grab Greg Shackles book ( http://www.amazon.com/dp/1449320236 ) to get an idea of whats needed for iOS+WinPhone+Android style development.
My hunch is that the companies you talked to simply are used to using Objective-C. That's where their skills lie, and that's the biggest reason why they would prefer not to deviate from their path. The other reasons can be argued both ways.
It's true that no one can predict what Apple will do, but there's a very small likelihood that Apple will ban third-party toolkits & APIs like they did in the summer of 2010. That was only a short period of time, and they completely reversed that decision. Their current focus is on making app development easier, which means keeping the field open to alternative development methods. I think MonoTouch is safe.
As for speed, C# generally produces very fast executables. They may not be quite as fast as Objective-C, but I doubt you'd notice a difference. I remember seeing a website somewhere that showed C# outperforming C/C++ in some tests, but that was in the .NET environment, not Mono... and unfortunately I can't find the reference anymore. I'll keep looking. But the bottom line on speed is that C# speeds are very good. It's not like BASIC vs C. More like Java/JIT vs C.
C# gives you many, many(!) advantages over Objective-C, and they have been enumerated in other Stack Overflow answers, so I won't repeat them here. You can find them easily enough.
I'm an obvious fan of MonoTouch, but I do have to say one thing: I think it's a mistake for companies to think that because they are fluent in C#/.NET that they will easily be able to develop and/or maintain iOS apps using MonoTouch. It's just not true, because MonoTouch is basically a C# layer over the CocoaTouch API, meaning that you have to learn the Apple way of doing things. You have app delegates and view controllers and all the UIKit stuff. There's a real learning curve there. But if you're fluent in C#, MonoTouch will be a huge help.
UPDATE:
I found the article on C# speed: Head-to-head benchmark: C++ vs .NET
I have actually used MonoTouch for every app I've ever developed. Performance has never been an issue, and I can't imagine how bad for me it would have been using Objective-C. I've had 2 top 10 apps in the US app store: "Draw A Stickman" and "Draw A Stickman: Episode 2" (don't worry we are working on more).
If you know C# and .Net your gains in productivity are going to be massive compared to what would happen trying to learn Objective-C. I was a C# .Net developer (Windows only) prior to iOS development and the transition to MonoTouch is great.
If you like Linq, parsing XML in fewer than 100 lines, garbage collection, generics, simple multi-threading, and no weird square brackets, MonoTouch is for you.
I use both Objective-C and c# (MonoTouch & Droid), and I really like both. When I'm coding in c#, there are plenty of features such as Linq which I'd love in Obj-C, & when I'm coding in Obj-C there are plenty of things I'd love to have in c#, but I adapt to whatever I'm coding in quickly enough. Re performance, I've detected no difference at all, even for fairly graphic-intensive stuff, so I wouldn't use that as a reason not to use c#.
I think it's ultimately down to what you're comfortable coding in, though of course with a well designed cross-platform project, you CAN have fully cross-platform core code if you use Mono, and you'll only have to do the UI stuff in a platform-specific way - when it comes to this obviously you'll need to know the native stuff to get your UIs working in a way which is appropriate to the platform and familiar to its users.
We have a line of business app that uses MS SQL as a data store, and has WinForms and web UI's. It integrates with our windows mobile 6.5 and tablet apps with web services. All c#.
We've fully committed to MonoTouch after some experiments in Objective-C and HTML-5 (we had working prototypes): we get to re-use our business logic, and we're comfortable developing new code in c#.
Our business logic is constantly being enhanced, and these enhancements are immediately visible to the mobile app - without having to replicate the logic in Objective-C or C++.
Our main issue is finding a c# programmer who's comfortable with the iPhone and iPad UI's.
MonoTouch is stable and we've encountered no limitations (we're binding to the same iOS API that Objective-C binds to). During our learning curve, we've had question, bumped into bugs and have had some misunderstandings - but the support from Xamarin is superb.
Performance has been a non-issue - our app is snappy even though it's doing a lot behind the scenes.
No body can tell you for sure what will apple support and what it will not support in the future, however apple had some issues with mono in the past, and since history tends to repeat itself, then it may be a possibility of that to happen again
Having said that, always go with the native application development SDKS and environments, it will be more flexible, and it will be updated real time, and performance will always be better in the native
We are currently running rails 2.1.
My main motivation for the upgrade is the fear that gems/plugins will get rarer/unavailable/unsupported day by day for our version (,and the excitement of the latest technology).
I understand there are many-many improvements that come with rails3, but probably what my manager would want to listen is the advantages that he'd get, in terms of the business.
Ours is a Saas application, load on the app is not very high, but the demand for reliability is more.
Edit :
Looks like my inclination towards the upgrade needs rethinking, so answers to "should I upgrade" are welcome.
my original question also needs answers - how to describe the business advantages of an upgrade from rails2.1 -> rails3.
The app is under active development/enhancements.
The longer you go without upgrading, the harder it will be when the time comes. Sooner or later, any actively maintained project is going to have to move up to the more recent versions, and the more versions you have to skip along the way, the harder and more risky it will be. If you upgrade regularly, it becomes a fairly simple maintenance task.
I'm afraid that going from 2.1 -> 3.0 is going to be a fairly rough one unless your app is pretty simple. You might try going from 2.1 -> 2.3.9 as a first step. However, doing it now, instead of when it's 2.1 -> 3.1 will save you heartache. Right now, everyone is focused on helping people upgrade. A year from now, there will be fewer fresh resources available and fewer people going out of their way to help people upgrade.
If your application is under development and is likely to have more and more features over the months to come then you should migrate to the newer and actively supported version.
If your application only needs bug fixes occasionally then you should stick to the current version.
Upgrade!
I'd say that you should definitely upgrade, for the reasons you stated, but don't rush it. If you have a well defined test suite everything should be ok.
Most of core Rails 2.x code works with Rails 3, you can just read the deprecation warnings and fix things one by one. You can also use the official Rails Upgrade plugin to automate the bulk of the editing.
As for the gems and plugins you use, you can check their compatibility at railsplugins.org and decide if it's worth the trouble if any.
And the elevator pitch for the boss: You said the app is under development, so upgrading later when you absolutely have to means that you have to first deal with all the issues arising under 2.x and then deal with the upgrade issues plus 3.0 issues of a much bigger app. Upgrading now saves time by saving you the trouble of having to deal with 2.x issues. And you also avoid some of the upgrade issues since your app is probably much leaner now than the heavyweight it will be when you decide to upgrade later.
Since reliability is high on priority, you should probably not upgrade unless it's absolutely required. Some unforeseen issue is bound to come up.
To address the excitement of the latest technology, you can always try out new plugins and Rails 3 offline.
Businesses should not be sandboxes of developers. Nor should development be Resume Driven.
But that's just my opinion. :)
There are several reasons to upgrade, all of which are under the assumption that the app is and will continue to be under active development.
Integration with 3rd party software- for example, rails 1 did not have ActiveSupport. An app remaining on rails1 all through say rails 2 might want to integrate with a 3rd party API that primarily supports restful json. At that point, the sensibile path is to upgrade, but since you delayed it so long your risk of having lots of issues in the upgrade will be significantly greater than if you upgraded early.
Using plugins that will help with new features - if you want to add a new feature and someone has scratched your itch already, then if you are stuck on an older version of rails you will have to write that code yourself. The more code you have to write yourself, the greater the likelyhood of bugs and the more maintaince the code will likely require, depending on the function.
Fixing bugs in older verisons of the plugins/gems - if you encounter a bug in rails, or a plugin, or a gem, or some sort of other integration issue, it might be fixed in a later version, but what that depends on a newer version of rails. This will make your path to fixing said bug or implementing said enhancement greater the longer you wait to upgrade.