Xcode 13.2 Beta release notes features a promise for Swift Concurrency support for iOS 13.
You can now use Swift Concurrency in applications that deploy to macOS 10.15, iOS 13, tvOS 13, and watchOS 6 or newer. This support includes async/await, actors, global actors, structured concurrency, and the task APIs. (70738378)
However, back in Summer 2021 when it first appeared at WWDC it was hard constrained to be run on iOS 15+ only.
My question is: what changed? How did they achieve backwards compatibility? Does it run in any way that is drastically different from the way it would run in iOS 15?
Back-deploying concurrency to older OS versions bundles a concurrency runtime library along with your app with the support required for this feature, much like Swift used to do with the standard library prior to ABI stability in Swift 5, when Swift could be shipped with the OS.
This bundles parts of the Concurrency portions of the standard library (stable link) along with some additional support and stubs for functionality (stable link).
This bundling isn't necessary when deploying to OS versions new enough to contain these runtime features as part of the OS.
Since the feature on iOS 15+ (and associated OS releases) was stated to require kernel changes (for the new cooperative threading model) which themselves cannot be backported, the implementation of certain features includes shims based on existing functionality which does exist on those OSes, but which might perform a little bit differently, or less efficiently.
You can see this in a few places in Doug Gregor's PR for backporting concurrency — in a few places, checks for SWIFT_CONCURRENCY_BACK_DEPLOYMENT change the implementation where some assumptions no longer hold, or functionality isn't present. For example, the GlobalExecutor can't make assumptions about dispatch_get_global_queue being cooperative (because that threading model doesn't exist on older OSes), so when backporting, it has to create its own queue for use as the global cooperative queue. #objc-based actors also need to have their superclass swizzled, which doesn't need to happen on non-backdeployed runtimes. (Symbols also have to be injected in some places into the backdeploy libs, and certain behaviors have to be stubbed out, but that's a bit less interesting.)
Overall, there isn't comprehensive documentation on the exact differences between backdeploying and not (short of reading all of the code), but it should be safe to assume that the effective behavior of the backdeployed lib will be the same, though potentially at the cost of performance.
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
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.
I just came to realize that my project is currently using methods that are "discouraged" in iOS 4.0+. I fear that deprecation is soon inevitable. However, in practical terms, I'm not sure what this would mean for my project. Does it mean that users who attempt to run the app on a future iOS version will experience runtime errors or does it simply mean that I'll have compile-time errors when maintaining it on future iOS SDK's? Or, am I missing the boat (and the river) entirely?
Thanks
It's unlikely that they'll remove the old method entirely, Apple just suggests (see "Animations") that you use the newer format.
As stated, if you want your projects to support iOS versions <4.0, continue using the old format. If not, it's recommended to update, but if you choose not to, don't be too worried about it. (at least not until the old format becomes officially deprecated)
EDIT: Just re-read the question, and to answer that specifically; no, not you nor any other users would experience errors in the future (provided you're using the functions correctly) - even if it does become deprecated.