One of the problems I find with Swift is that Apple doesn't go back and properly update their sample code at developer.apple.com. They have examples that will not build. If you search you can find folks that have patch sets, but they really need to fix the examples.
And just today I was contemplating writing my first native iOS and macOS app... I was looking at the options and decided to go native with Swift. I have never written Objective-C app and never used x-code for dev. But I have ~10 years of dev experience, mostly Java and Python on the backend and front end dev exp mostly with Angular. Some Android, and a little from <input_random_tech_here> because I like to experiment.
So, my question is. How hard and enjoyable is for someone like me to write not very complex native iOS/macOS app in Swift starting from scratch? Best resource to start with?
Hardest part isn't the language. Swift is among the best languages you can get today. IOS sdk, on the other hand, has become a bit of a mess, due largely to the pace at which the field is moving ( although not as bad as android).
I'm surprised no one has mentioned this but I'd say the #1 resource for learning the practical 'how do I get X thing done in a couple of hours' are tutorials on https://www.raywenderlich.com/ without a doubt.
It has tutorials for every basic question imaginable in a very easy to follow manner.
It'll definitely take some time, as for being enjoyable - I don't get a kick out of learning an entire new set of libraries and idioms for achieving the same thing I can do in another toolset, but if you do, then great :)
One last thing - the amount of information for macOS is about 1% compared to iOS, so I'd definitely go the iOS route.
Depending on complexity of your app and the level of polish, it might take a while.
I mean, you can make an app in a day if you follow a tutorial, but if you want to enjoy the language and what you're doing, then you'll have to put in the effort.
Objective-C can probably be avoided, but will help a lot in some cases - especially when interfacing with libraries written in ObjC or C++. So you might want to learn them in parallel, or at least spend a bit of time understanding the semantics of the language, memory management, concurrency, etc.
Oh and native iOS is different from native macOS, some APIs are not compatible, but you can reuse quite a bit of utility-level functions related to your app (since it's the same language).
I enjoyed learning ObjC and Swift and writing apps for iOS, the only issue I have with this platform is that it's too crowded for (new) solo devs.
If you don't care about that as much, then by all means go ahead, you will love it.
Regarding iOS and macOS kits, all of the documentation is in Objective-C. The libraries' Obj-C is imported and usable with Swift-only code, but the Swift documentation lazily links you to examples in the Obj-C docs. You have to perform trial-and-error by manually converting the Obj-C examples into the equivalent Swift (which often entails renamed classes, methods, types, etc.).
If your projects typically do a lot of string parsing, get ready for a world of hell. Swift 4 didn't improve upon the very basic ability to extract a substring from the middle of a string. It takes 3-4 lines of code, with throwaway explicitly defined variables, to do the equivalent of a str.substr(start, end|length). It boggles the mind that you can't do a str.utf8.substr(3, 5) in Swift.
You'll get up to speed in no time. Start with WWDC videos [1] in an area you're interested in. Then play around with some of Apple's sample code [2] and modify an app to your liking.
After you're a little more advanced, check out the resources at objc.io [3].
I did this a couple of years ago on a completely fresh MVP for a friend.
Worked fine, my background was in trading systems using C#, Python, and C++. I'd also done a lot of Android Java for another app MVP, so interesting to compare how iOS and Android do things.
I think most people who've done a few languages are not going to find a lot of problems with Swift. There's a lot of nice sugar in there to keep things neat.
Your main issue if you haven't done iOS before is learning iOS. It's a bit weird, you can tell some libs haven't been upgraded while others have. The old libs need a bridge header and have weird relics from Obj-C. Also the whole constraints layout system might take some getting used to, but I did manage to build some pretty complex components with it. It didn't seem to map well onto the Android layout engine, but I'm not that experienced with the layout engines.
I suspect that with your Java, you'll find Swift to be a snap to get started in, particularly if you've also experimented ever with Scala. Mastering idiomatic Swift is a bit harder, but definitely doable with a bit of effort.
I think you'd pick up Swift pretty easily given your polyglot background, but if you already know javascript and you aren't doing something that screams to be native, RN would be my choice. You'll get to work in a familiar language, and get an Android version with much less work than if you do swift.
Maybe someone will explain this to me. Does Swift use this confusing "rapid release" versioning? Does Swift 4 break backwards compatibility with Swift 3?
In my company people are looking for a language to rewrite some legacy Objective-C to. Swift is often discarded as "unstable" because of these major version bumps. Compare this to Go, which, seven or so years after the initial release is still 1.x and still doesn't break code.
I just don't get breaking the language so often. Do people enjoy rewriting code?
I wish more effort were being made to make it a first class citizen on non-Apple platforms. With the popularity it has enjoyed, it could easily challenge the likes of Go, Python or even Java for server side programming.
The linked post talks about concurrency not being a focus until Swift 6 at the earliest. Personally, I don't want to make a commitment to server-side Swift until after that dust has settled.
Agreed - I'd love to see it more widely adopted. It's a great language.
Once both ABI stability and a native concurrency model have been implemented, Swift would be in an even stronger position to take on these languages. I'm not sure that's the sole reason a stronger push hasn't been made yet, but waiting another few years to go after this goal would in some ways be tactful.
I've been sort of going back and forth on what I want to work on as a side project, but server side Swift stuff is definitely an option. I love the language, and think it could end up being a really strong competitor in that space. At the moment it's just barely viable though, sadly.
You should definitely try rust, it's better than its counterparts, rapidly growing, memory safe language with utmost priority on efficiency. Plus its cross-platform too :)
Can someone with Swift experience comment on the status of Swift on non-Apple platforms? Is it being used outside of the Apple ecosystem? How is the tooling, deployment, availability/support, etc.
Victim of trying it the first week it came out, having to call down into C for anything POSIX, and giving up. If you don't have POSIX bindings, don't call yourself v 1.0.
Currently trying a web framework, developping on a mac and running it on unbuntu ( vapor framework). I'm extremely positiely surprised by the user experience. Installation is easy, xcode is working fine with autocomplete, libraries seem good enough ( db querying on postgres using a default ORM seems to work).
I've now started to investigate deployment on ubuntu, and the only regret so far is that cloud platform don't support this language very well at the moment ( app engine with dockerfile is a pita, and i gave up to more regular engine instances).
I think starting to develop very basic web apps on this language is beginning to make sense.
It's a second class citizen and official examples and community tend to heavily rely on Apple OS provided libraries and APIs to do their work.
The implementations of standard libraries are currently far from perfect.
Unfortunately it seems to me that Swift on non-Apple platforms will forever be stuck in Mono-like role: "kinda working", but always the second class citizen that just waits to spring a hard-to-debug issue on you due to different implementation of underlying libraries.
I wouldn't trust it with production code, especially considering how many other stable and properly supported cross-platform languages exist.
I've been maintaining a project at work since Swift 2, where the goal has always been to add Linux support (in addition to macOS and iOS) as soon as it is viable. That project's fairly simple requirements include basic HTTPS networking, JSON encoding/decoding, managing multithreaded operation queues, and defining a hierarchy of objects to model an API's data structures. It doesn't need a GUI.
So I've looked at each Swift release through the lens of "Can we add Linux support yet?", and I would say Swift 4 will be the first release where it is viable. Viable, but still with caveats:
1.) The best tooling is still Xcode; the best way to write Swift code for Linux is to do it on a Mac with Ubuntu running in a VM, sharing the Mac's filesystem. Of course you can write code on Linux, but there are no editors that have more than a rudimentary set of Swift tools for code-completion, static analysis, or visual debugging.
2.) There are still many landmines lurking in the standard libraries on Linux. These are mostly obvious when you find them; various parts of the Foundation library (which is a Swift-native reimplementation of Apple's core framework for building apps, including basic networking, filesystem access, unicode string stuff, URL manipulation, UUIDs, etc.) have parts where the interface is there but the implementation on Linux just calls NSUnimplemented(), which immediately traps and halts the program. Fortunately, there are far fewer of these places in Swift 4 than Swift 3.
For this reason, if you are writing cross-platform Swift code that needs to run on macOS and Linux, you will probably find yourself using Swift's #ifdef-like "#if os(Linux) ..." feature to conditionalize execution based on the platform.
3.) Testing is a pain, because unlike on Apple platforms, which can borrow objc runtime features to do weird magic, Swift's native reflection capabilities still are not very strong, preventing it from doing useful things like finding and executing all your test cases automatically. You have to add an "#if os(Linux)" section to each test case class, and then manually add redundant boilerplate for each test method that your write. The more tests you write and refactor, the more annoying this is.
4.) Nothing works at first. It's not straightforward to just unpack a dev release and get basic things working: importing libraries into the REPL, debug on Linux using lldb. Those things do work but you will have to visit the Swift JIRA tracker and to learn the magic collection of permission changes, command-line flags, and environment variables that make it all possible.
5.) If Swift had a good answer for interprocess communication it would be awesome as a kind of scripting language. However, it does not. It has this terrible API based on the old Mac NSTask class, and you will probably end up abandoning that and trying to write an interface to popen(), write 100 lines of error-handling code just to launch some UNIX tool and get its result, rub your eyes, sigh, close the editor, delete the file, and write it in ruby or python.
However, there is also some really awesome stuff:
a.) Swift itself is awesome to program in, and except where explicitly unimplemented, it is stable and fast on Linux.
b.) Swift Package Manager is now robust and a pleasure to work with.
c.) The build system works great on Linux, aside from the slowness of a young compiler (which is not specific to Linux).
d.) The new Codable API for serialization is significant because none of the popular JSON libraries for Swift worked well on Linux (IBM had a fork of one that was purported to work). Now, it's built-in, awesome, and works great on Linux.
e.) If a web-delivered app UI is a requirement, there is some really awesome competition going between Vapor (I think still the most popular Swift web framework) and IBM's Kitura web app framework. Considering how niche Swift still is for web development, there is an amazing level of work being done in this area.
That's on off-the-top-of-my-head summary of where Swift on Linux is. I don't think it is at all advanced yet on any other non-Apple platforms.
Since things at Tesla haven't worked out, I hope Lattner eventually returns to Apple.
Not that the Swift team is in a bad shape without him, it's just that it's nice to have an amazingly smart guy behind an open source language that many of us use (and that number that will probably only grow).
Swift developers, how is the evolution of the programming language now? does it still have backwards compatibility issues or things are more stable now (and will be with this new proposals)?
About concurrency : does anyone know of a language that would let you tag portions of a codebase in some way, and declare something like "all those methods should execute in the same thread". Those declarations would then be checked by the compiler.
That would be a first step toward agent like concurrency, but it would be general enough to apply to other types of concurrency models.
That's an interesting concept. Would you also suggest having a way of saying "this method should execute in another thread" or "all of those methods should execute in another thread"?
The only complaint about swift programming is: they keep changing the programming interfaces, so if I import a third-party code file written with earlier versions of Swift, I have to go through the errors of 'obsolete APIs', updating the function signatures. The changes are automated by Xcode, but it is still a hassle.
I am totally OK with introducing new features of Swift language. But changing the API function signatures (even multiple times) seems totally unnecessary, and reflects the API designers' obsession of naming conventions.
Tangential question- I'm in the UK and I am keen to become a iOS developer (I'm currently a senior .NET developer in a large firm). Are there enough opportunities remaining in iOS development as a contractor / creator of ('enterprise') apps to make a living? I would be very grateful if anyone could share any advice / personal experience.
> the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by requiring that all proposals have an implementation before they are officially reviewed by the Core Team.
Good. They are effectively saying 'Talk is cheap, show me the code'
[+] [-] protomyth|8 years ago|reply
[+] [-] ssijak|8 years ago|reply
So, my question is. How hard and enjoyable is for someone like me to write not very complex native iOS/macOS app in Swift starting from scratch? Best resource to start with?
[+] [-] bsaul|8 years ago|reply
Stanford courses are the best you can find online for free. https://youtu.be/HitSIzPM_6E
[+] [-] alexashka|8 years ago|reply
It has tutorials for every basic question imaginable in a very easy to follow manner.
It'll definitely take some time, as for being enjoyable - I don't get a kick out of learning an entire new set of libraries and idioms for achieving the same thing I can do in another toolset, but if you do, then great :)
One last thing - the amount of information for macOS is about 1% compared to iOS, so I'd definitely go the iOS route.
[+] [-] delegate|8 years ago|reply
I mean, you can make an app in a day if you follow a tutorial, but if you want to enjoy the language and what you're doing, then you'll have to put in the effort.
Objective-C can probably be avoided, but will help a lot in some cases - especially when interfacing with libraries written in ObjC or C++. So you might want to learn them in parallel, or at least spend a bit of time understanding the semantics of the language, memory management, concurrency, etc.
Oh and native iOS is different from native macOS, some APIs are not compatible, but you can reuse quite a bit of utility-level functions related to your app (since it's the same language).
I enjoyed learning ObjC and Swift and writing apps for iOS, the only issue I have with this platform is that it's too crowded for (new) solo devs.
If you don't care about that as much, then by all means go ahead, you will love it.
[+] [-] developer2|8 years ago|reply
If your projects typically do a lot of string parsing, get ready for a world of hell. Swift 4 didn't improve upon the very basic ability to extract a substring from the middle of a string. It takes 3-4 lines of code, with throwaway explicitly defined variables, to do the equivalent of a str.substr(start, end|length). It boggles the mind that you can't do a str.utf8.substr(3, 5) in Swift.
[+] [-] shanev|8 years ago|reply
After you're a little more advanced, check out the resources at objc.io [3].
[1]: https://developer.apple.com/videos/
[2]: https://developer.apple.com/library/content/navigation/
[3]: https://www.objc.io
[+] [-] lordnacho|8 years ago|reply
Worked fine, my background was in trading systems using C#, Python, and C++. I'd also done a lot of Android Java for another app MVP, so interesting to compare how iOS and Android do things.
I think most people who've done a few languages are not going to find a lot of problems with Swift. There's a lot of nice sugar in there to keep things neat.
Your main issue if you haven't done iOS before is learning iOS. It's a bit weird, you can tell some libs haven't been upgraded while others have. The old libs need a bridge header and have weird relics from Obj-C. Also the whole constraints layout system might take some getting used to, but I did manage to build some pretty complex components with it. It didn't seem to map well onto the Android layout engine, but I'm not that experienced with the layout engines.
[+] [-] physicsyogi|8 years ago|reply
[+] [-] caiob|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] jnbiche|8 years ago|reply
[+] [-] smegel|8 years ago|reply
Your biggest problem won't be the language, but the 30,000 other apps uploaded to the App Store every single day.
[+] [-] andrewljohnson|8 years ago|reply
I think you'd pick up Swift pretty easily given your polyglot background, but if you already know javascript and you aren't doing something that screams to be native, RN would be my choice. You'll get to work in a familiar language, and get an Android version with much less work than if you do swift.
Best resource to start a react native app I'd say is this, it was really easy for me: https://facebook.github.io/react-native/docs/getting-started...
For Swift, here's a page from Apple, but I just plucked it from Google: https://developer.apple.com/swift/blog/?id=16
[+] [-] ainar-g|8 years ago|reply
In my company people are looking for a language to rewrite some legacy Objective-C to. Swift is often discarded as "unstable" because of these major version bumps. Compare this to Go, which, seven or so years after the initial release is still 1.x and still doesn't break code.
I just don't get breaking the language so often. Do people enjoy rewriting code?
[+] [-] __sr__|8 years ago|reply
[+] [-] bjt|8 years ago|reply
[+] [-] jordansmithnz|8 years ago|reply
Once both ABI stability and a native concurrency model have been implemented, Swift would be in an even stronger position to take on these languages. I'm not sure that's the sole reason a stronger push hasn't been made yet, but waiting another few years to go after this goal would in some ways be tactful.
[+] [-] brian_herman|8 years ago|reply
[+] [-] jrs95|8 years ago|reply
[+] [-] xenadu02|8 years ago|reply
[+] [-] heja_bruh|8 years ago|reply
[+] [-] jswny|8 years ago|reply
[+] [-] crb002|8 years ago|reply
[+] [-] bsaul|8 years ago|reply
I've now started to investigate deployment on ubuntu, and the only regret so far is that cloud platform don't support this language very well at the moment ( app engine with dockerfile is a pita, and i gave up to more regular engine instances).
I think starting to develop very basic web apps on this language is beginning to make sense.
[+] [-] cgb223|8 years ago|reply
I've never actually seen it in production though, nor have I heard of any of my friends companies either
[+] [-] izacus|8 years ago|reply
The implementations of standard libraries are currently far from perfect.
Unfortunately it seems to me that Swift on non-Apple platforms will forever be stuck in Mono-like role: "kinda working", but always the second class citizen that just waits to spring a hard-to-debug issue on you due to different implementation of underlying libraries. I wouldn't trust it with production code, especially considering how many other stable and properly supported cross-platform languages exist.
[+] [-] veidr|8 years ago|reply
So I've looked at each Swift release through the lens of "Can we add Linux support yet?", and I would say Swift 4 will be the first release where it is viable. Viable, but still with caveats:
1.) The best tooling is still Xcode; the best way to write Swift code for Linux is to do it on a Mac with Ubuntu running in a VM, sharing the Mac's filesystem. Of course you can write code on Linux, but there are no editors that have more than a rudimentary set of Swift tools for code-completion, static analysis, or visual debugging.
2.) There are still many landmines lurking in the standard libraries on Linux. These are mostly obvious when you find them; various parts of the Foundation library (which is a Swift-native reimplementation of Apple's core framework for building apps, including basic networking, filesystem access, unicode string stuff, URL manipulation, UUIDs, etc.) have parts where the interface is there but the implementation on Linux just calls NSUnimplemented(), which immediately traps and halts the program. Fortunately, there are far fewer of these places in Swift 4 than Swift 3.
For this reason, if you are writing cross-platform Swift code that needs to run on macOS and Linux, you will probably find yourself using Swift's #ifdef-like "#if os(Linux) ..." feature to conditionalize execution based on the platform.
3.) Testing is a pain, because unlike on Apple platforms, which can borrow objc runtime features to do weird magic, Swift's native reflection capabilities still are not very strong, preventing it from doing useful things like finding and executing all your test cases automatically. You have to add an "#if os(Linux)" section to each test case class, and then manually add redundant boilerplate for each test method that your write. The more tests you write and refactor, the more annoying this is.
4.) Nothing works at first. It's not straightforward to just unpack a dev release and get basic things working: importing libraries into the REPL, debug on Linux using lldb. Those things do work but you will have to visit the Swift JIRA tracker and to learn the magic collection of permission changes, command-line flags, and environment variables that make it all possible.
5.) If Swift had a good answer for interprocess communication it would be awesome as a kind of scripting language. However, it does not. It has this terrible API based on the old Mac NSTask class, and you will probably end up abandoning that and trying to write an interface to popen(), write 100 lines of error-handling code just to launch some UNIX tool and get its result, rub your eyes, sigh, close the editor, delete the file, and write it in ruby or python.
However, there is also some really awesome stuff:
a.) Swift itself is awesome to program in, and except where explicitly unimplemented, it is stable and fast on Linux.
b.) Swift Package Manager is now robust and a pleasure to work with.
c.) The build system works great on Linux, aside from the slowness of a young compiler (which is not specific to Linux).
d.) The new Codable API for serialization is significant because none of the popular JSON libraries for Swift worked well on Linux (IBM had a fork of one that was purported to work). Now, it's built-in, awesome, and works great on Linux.
e.) If a web-delivered app UI is a requirement, there is some really awesome competition going between Vapor (I think still the most popular Swift web framework) and IBM's Kitura web app framework. Considering how niche Swift still is for web development, there is an amazing level of work being done in this area.
That's on off-the-top-of-my-head summary of where Swift on Linux is. I don't think it is at all advanced yet on any other non-Apple platforms.
[+] [-] dottrap|8 years ago|reply
https://academy.realm.io/posts/swift-on-android
Young but potential.
[+] [-] frik|8 years ago|reply
How good is the ecosystem for server side applications on other OS?
I like the syntax of Swift, it would be awesome to be able to use it for iOS apps as well as server apps.
[+] [-] samcat116|8 years ago|reply
[+] [-] tambourine_man|8 years ago|reply
Not that the Swift team is in a bad shape without him, it's just that it's nice to have an amazingly smart guy behind an open source language that many of us use (and that number that will probably only grow).
[+] [-] jorgemf|8 years ago|reply
[+] [-] bsaul|8 years ago|reply
That would be a first step toward agent like concurrency, but it would be general enough to apply to other types of concurrency models.
[+] [-] tonyg|8 years ago|reply
[+] [-] comex|8 years ago|reply
https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
You can create a dummy ‘lock’ type that just represents being on a certain thread, with corresponding global variables for different named threads.
[+] [-] whowouldathunk|8 years ago|reply
https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
[+] [-] BinaryIdiot|8 years ago|reply
[+] [-] cmoscoso|8 years ago|reply
[+] [-] Jack4E4B|8 years ago|reply
[+] [-] slavapestov|8 years ago|reply
[+] [-] real-hacker|8 years ago|reply
I am totally OK with introducing new features of Swift language. But changing the API function signatures (even multiple times) seems totally unnecessary, and reflects the API designers' obsession of naming conventions.
[+] [-] martijn_himself|8 years ago|reply
[+] [-] geodel|8 years ago|reply
Good. They are effectively saying 'Talk is cheap, show me the code'
[+] [-] the_common_man|8 years ago|reply
[+] [-] seekler|8 years ago|reply
[+] [-] apple4ever|8 years ago|reply
[+] [-] legulere|8 years ago|reply
[+] [-] haterswillhate|8 years ago|reply
[deleted]
[+] [-] RocketSyntax|8 years ago|reply