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.
This! I tried to learn Swift with the playground that came from "A Swift Tour"... A lot of examples didn't compile and it took WAY too long to figure out that it wasn't a problem on my end.
Definitely not a good way to introduce new programming languages to newbies.
I downloaded "A Swift Tour" a week or two ago and it was written in Swift 4 (a fact which I found out when I tried to run it in Swift Playgrounds 1.5). When did you try it?
I don't think that matters. The iOS Swift community is large enough that there's lots of example code. I've got almost 7000 urls in my database of Swift blogs:
Most topics get sufficient coverage. If you don't mind paying a small monthly fee, Ray Wenderlich's site has lots of tutorials that are well maintained. Plenty of free examples too:
Seconded on Lets Build That App. Found about it last week, and bought the subscription asap - was impressed with the quality.
However, I was an iOS dev 3-4 years ago and wanted to learn swift - so, it was a pretty smooth upgrade for me. I think whoever wants to learn iOS dev might be better off learn the basics more thoroughly and then come back to this course.
Definitely recommend visiting their list of swift blogs. Nicely aggregates different sources, as a primarily iOS dev, it's a great way for me to catch up every once in a while on the dozens of blogs I don't want to follow daily.
Yeah, right, that is some serious BS right there. I've filed radars on the Finder (multiple with reproducible crashes), location data, and Quicktime and it holding onto external drives. The only one they have ever fixed is the Quicktime bug but it reappeared later then went away again.
Apple is horrible about bugs and providing feedback. Why the heck would I need to file a radar anyway? Doesn't someone at Apple check the examples to make sure they still work? These are the examples Apple uses to promote and teach the language and how to build apps.
> Apple is horrible about bugs and providing feedback.
Yes, they can be a bit tight-lipped. I have found that they're pretty quick on fixing documentation though. They won't tell you that it's resolved, but it's usually updated within a couple of days.
> Doesn't someone at Apple check the examples to make sure they still work?
I'd expect that they do, but some slip through the cracks. Maybe on of the Apple engineers in this thread could weigh in?
Apple are super slipshod about their documentation in general. Hardly a day goes by that I don't get a Stack Overflow comment telling me that some link to Apple's docs is broken.
Ive filed before but they still send back the same docs about coreLocation, funniest is when the update is for Swift but they just send me the Apple docs with Obj-C (only has Obj-C, no swift for years), a swift beginner would never understand, I can because I can translate but its pretty frustrating still because you're still guessing thats the right way.
Developer documentations should start following API like structures. For example, in API land we have:
/api/v1/users
/api/v2/users
This means that making requests to v1 will only work with v1 and v2 only with v2. This makes sure that the API you are connecting to is using the correct parameters for its version.
Going back to documentations, they should state in the examples or in the documentation that this document is written for V2 of swift or anything more specifc. Even better would be sticking to Semver like specifications for the versioning.
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).
If you know, say Agda, Idris is not hard. The point is the concepts in Idris are hard, not the language. People learning haskell as first language in universities have more difficulty learning OO language than we have as we already know many OO languages.
The Android framework is honestly a huge pain to develop with. I switched over to iOS development a year ago and am much happier. It feels almost impossible to get Activity/Fragment life cycles correct for simple things. And anything View related has to pass around a God Context object.
For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other.
IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) and swift relies on compile-time codegen hack to provide easy struct serialization, because techs like nscoding relied on obj-c runtime facilities and the language itself doesn't provide enough metaprogramming facilities to compensate.
Also, patterns like KVO are still found from time to time as a last resort in frameworks, while being famously unsafe and still rely on the obj-c runtime.
For android basically everything should be rewritten from scratch. Last time i managed a team of android developpers, we basically came to the conclusion that doing regular mvc while supporting a good market share meant recoding our own controller base classes and screen transitionning apis.
>> For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all)
I disagree with most of this. Laying out views was a mess for a while but auto layout is easy to get right once you understand the fundamentals (especially when used in storyboards). Springs and struts is old pre-autolayout tech which shouldn't be used. CALayer is the lower level object that UIView is based on. Not sure what the complaint is here (they're mostly unrelated to autolayout/springs and struts).
As for CoreData it's a pretty simple way to manage your data. When originally introduced to iOS it was a mess but I've used it extensively in the last few years, first through a higher level framework (MagicRecord I think?) and now directly and it providing you exercise some care around threading it performs very well, especially for something simple like offline data storage.
Ever tried to have 60fps on a tableview with constraint-based layout cells ? CALayer is definitely not legacy, it's often the only way to get smooth animation. Spring n struts is also sometimes the best way to get fast position for smooth scrolling.
Ever had to deal with Core Data migration on an app that needs to evolve throughout the year ? Migration is a mess, and so is concurrency.
My personal conclusion after having used Core Data on a pro application for 4 years, is that most of the time i really don't need a database and so i'm back to file-based backups for my app's data. Works well, no magic, and no performance or threading issue.
We ran some casual benchmarks on this at work once, and it's important to note that the performance of AutoLayout dramatically improves based on the degree of nesting you employ.
If you have sixteen views on a cell and their locations all depend upon each other, it's going to take a long time to solve those constraints. But if you can break up the cell, say into four subviews with four elements inside them, it's likely to be faster (no guarantees, though)
Yup, it's easiest if you understand what the solver is doing and help point it towards solutions/find them trivially.
Unfortunately, i had to write my own constraint system and practice with it a lot to use AutoLayout with high performance where i was confident i was not introducing significant re-layout performance problems.
I came to the same conclusion WRT core data. I'm caching data myself to files. I would use SQLite directly if I need a real data store before I would use code data again
How in the world did you managed to use storyboard? I hate using it for moderate-complex UI apps. This guy say it better than me on why I hate storyboard (especially the first reason):
I use it in combination with programmatic UI for more complex things but find it's so much easier and faster when doing auto layout to just use storyboards.
The real reason for which i stopped using them is that it doesn't work well with git. As soon as you've got more than one people in the team, it's over.
It is actually a solvable problem if you're willing to dig into the details of the file changes. It isn't pleasant, but welcome to life. Team members can make conflicting changes as long as someone is willing to dig through the mud to make them all agree with each other. I've been doing it personally for a long time, it isn't my favorite part of the job but it does enable significant parallel productivity.
So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control. Note that since Android copied many metaphors from iOS, it also inherited these complexities in things like its Activity class.
I agree that Core Data probably needs to go away (at least its iCloud integration) and be replaced by Firebase or PouchDB etc.
KVO was a great missed opportunity because it's not clear who is watching a value. I think the pattern itself has merit from a functional programming perspective (after all this is how Excel works).
I generally avoid native mobile development now for these reasons among many, not to mention cross-platform issues. We likely need web metaphors running above native code, writing plugs where necessary (like Cordova or React Native). These are generally quite painful to use though, so I don't see many solutions materializing for at least several more years.
>So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control.
Why on earth would you have a single blocking thread on a UI app?
What I was trying to say is that in the olden days of say the 80s, Mac OS used cooperative threads and you just wrote a main loop that was completely self-contained. We made OS calls from there, the OS didn't call us with events like it does today (at least most of the time). So programs were much simpler to debug because we didn't have callback or goto hell.
The tradeoff was that it took pages of boilerplate to make even the simplest app, and Apple got made fun of incessantly for it. So they largely fixed that with OS X's message passing metaphors, but unfortunately due to bloat and a lot of other reasons, the boilerplate issue came back, and now we're also stuck with untraceable program flow.
To answer the original question - I have worked on both blocking and nonblocking code, and unfortunately nonblocking code doesn't scale. It eventually becomes too complex to follow the flow. It's like comparing a coroutine to a state machine. My personal feeling is that we're in a kind of nonblocking bubble right now and that the callback style that pretty much all frameworks use today is not going to be the way it's done in the future. I don't know what will replace it, but it will likely be something more like Redux/Elm/Clojure and declarative GUI syntax like how the web used to work.
It also doesn't help that these APIs are rapidly changing, in ways ranging from minor rearrangements that the XCode auto-upgrader can mostly handle, to real porting hassles. I've been working on a project that was started in early 2016, so it was originally in Swift 2, the then-current version. A ton of things changed for Swift 3, which came out 6 months later, in late 2016. And a bunch of things are changing again with Swift 4 (although not as many as in the 2->3 upgrade). I haven't yet looked into Swift 5, but presumably that brings yet more API changes.
A lot of time is spent just on this treadmill of porting previously working things to modified APIs. To make it worse, you have to manage a 4-way compatibility matrix between Swift versions, XCode versions, iOS versions, and macOS versions, where only very specific combinations work.
AFAIK Swift 3 was supposed to be the last version to introduce breaking changes. Have they changed that policy? I know that the last Swift update I did was very manageable compared to in the past (where I'd easily lose a day or two).
This project's still on Swift 3, so I don't have first-hand experience upgrading to Swift 4. It looks like there are breaking changes though, albeit not nearly as many as 3 had.
The most notable one looks like in the String API [1]. There are a few other minor ones that most projects won't hit, like in the dictionary/set API [2]. A few of these are also slightly more breaking than it initially seems because they've added temporary compatibility workarounds marked as deprecated in Swift 4 to avoid breaking as much working Swift 3 code, but these will go away for Swift 5, so you do still have to port anyway (just not immediately).
I don't see why keyed archiver wouldn't work with swift. I've implemented identical systems in C++ with no dynamic features. Or you can just use JSON serialization for offline storage. I pretty much never use core data. Don't get why people use it so much. On iOS you are a single user of your data so you can easly rely on a combination of plain files for storage. I've seen how Java devs go crazy using core data to just store a few hundred bytes of data. I think people overcomplicate storage 90% of the time.
Keyed archiver doesn't work with structs, and it also probably doesn't work whenevr you start nesting classes. It relies on introspection and dynamic typing for that, which can't work right now with swift.
It's one reason they had to rely on compile-time codegen to implement the swift4 equivalent.
For me it feels like the messaging is pretty clear: use AutoLayout. Springs and struts aren't used anymore, constraints are just a part of how AutoLayout works, and I'm not even sure what you mean by physic based.
I found myself wasting months to do something that should have been handled better in iOS.
- APIs return non-descriptive error codes like -16405. Some of them aren't documented. And even the ones that are are not found clearly. Different codes are documented in different files. If you don't know where to look, you won't find it. Java-style descriptive error names like InvalidFrameRateException are sorely missing. iOS should either adopt exceptions or at least string error codes like INVALID_FRAME_RATE, not -16405.
Sometimes, there's no error code at all. I'm trying to record a video, using a AVCaptureMovieFileOutput, which is supposed to save to a file, and it doesn't. There's no error code, no exception, no log message telling me what went wrong and how to fix it. I spent a day or two trying various possibilities but nothing worked.
- Common abstractions like a photo gallery class aren't missing. It took me a month to write my own, because there are a lot of cases to deal with: swiping left and right, pinching to zoom, double-tapping to zoom, keeping the photo centered while zooming, taking care not to zoom the whitespace, keeping the photo gallery in sync with the Photos app (the user might delete a photo either in your app or in the Photos app, and you need to sync in both directions), and so on. Even now my gallery class doesn't support swipe down to close, which the Photos app supports, as I was told yesterday. That's what happens when you make people reimplement things — you'll get an inconsistent UX.
Forget a photo gallery class. Even a zoomable photo view is missing. It took me days of messing with UIScrollView to figure this out, until I found the ray wenderlich tutorial.
- Some APIs come in both sync and async versions, while others, like permissions, come only in an async version, though a sync version would be easier. Even the async APIs are inconsistent -- some invoke your callback on the main thread (UIKit APIs), some invoke it on the same thread you invoked it on, and some in a random thread (AVCapture). I filed a radar asking for consistency (maybe all async APIs can take a queue to invoke the callback on) but Apple closed it as WontFix.
Unfortunately, Swift doesn't have async/await, so dealing with the async APIs is a pain, and for some reason, this is not even a priority in Swift 5. It's being put off for years.
- Permissions are a pain to deal with, especially the common case that your app can't run without some permissions, like Camera and Photos for a camera app. I had to deal with the following cases:
+ You should take care to request a permission only after the previous one has been approved or denied by the user. Otherwise, you'll get a prompt for Camera, and before you respond, it disappears and is replaced by a prompt for Photos. And before you can respond, it disappears and is replaced by Location. When you respond to it, the Camera prompt re-appears, but again disappears and is replaced by Photos. This is a bad UX, caused by iOS not queueing multiple permission requests internally and asking the user for one only after the previous request was responded to.
+ You should ask for location before camera, because a GPS fix can take time.
+ You should take care to obtain permission before accessing the camera, otherwise the camera will vend frames consisting of black pixels, which you might accidentally save to the Photos app.
+ iOS distinguishes between a permission being denied (by the user) and restricted (by an admin or parent). My app would crash in the latter case, because the camera device is not found. But not in the former, because the camera exists but vends black frames.
+ If the user changes permissions of your app while it's running, Apple says that iOS will kill your app and restart it so that you don't have to deal with permission changing dynamically. Except when it doesn't, which goes back to the denied vs restricted case above.
In summary, you waste months of your time working around insufficiently-documented iOS issues, or debugging things, or reimplementing common things in every app.
I conclude that iOS is a poorly-designed platform from the developer point of view. Maybe other platforms are worse, I don't know, but iOS certainly is far from what it could have been. Ideally, you should implement only what makes your app unique.
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.
> One last thing - the amount of information for macOS is about 1% compared to iOS, so I'd definitely go the iOS route.
I thought that too, but it’s not accurate at all, from recent experience. There is a lot of hidden treasure for macOS, but it is buried under layers of bad Google results because somehow “NSViewController” makes Google shows me results for “UIAppDelegate” and “UIView”—makes sense. A lot of information is out there, on SO, Apple developer forums and mailing lists.
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.
I only remember a very early review of string operation speeds that was pretty bad at times indeed. But that was about Swift 1 and the string implementation has been changed a few times. Do you have any recent source?
Personal experience making the same command line util in python and swift 3 that was parsing code with the same C library (sourcekit) and then doing a bunch of string manipulation after that.
Optimized swift 3 & python were the same speed, with %80 of the time being spent in the C library. I would expect swift would at least be 2x faster in that %20 portion that wasn't sourcekit library.
I think strings in Swift are primarily meant to be very correct above being fast or easy to use. It's more strict than both Python 2 and 3. Handling of languages that use really complex character compositions springs to mind.
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.
Yeah, up-to-date was assumed in my post. I don`t want a post about Objective-C from 2012.
I don`t know if it is against the guidelines to post this kind of links but I found this https://designcode.io/ (I have 0 affiliations with the product) that looks just like what I need. From 0 to app in the newest stack, would probably buy and try it if somebody does not have something better in mind?
No idea how good that book is but that newest stack won't be the newest in maybe a month or so. Assuming that is well written most of it will be applicable or will need only minor updating. That's probably why no iOS dev (from the original comment) can find anything "up to date" because we're right on the edge of a new release.
> Yeah, up-to-date was assumed in my post. I don`t want a post about Objective-C from 2012.
What a ridiculous statement. Most of those resources are excellent and relevant today. An article/blog post on calendrical or localization or accessibility is still as relegate today, as “back in the day” in 2012. This is not some web “dev” nonsense where the “stack” changes every year and a half. iOS and macOS consist of some tried and tested APIs that are decades old.
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.
There is little “native” about React Native. It’s something web “devs” like to convince themselves because they don’t know better.
Using merely UIView objects does not mean it is native. It’s not just an abstraction over native. The “great” minds at Facebook have decided to not only offer a JS wrapper around the native APIs and objects, but actually reinvent the wheel on everything. Tables? Let’s have a horrible implementation in JS. Gestures? Slow ones in JS. Navigation? Absolutely terrible in JS. Animations? Core Animation you say? Nope, in JS or in C++. Even simple stuff like buttons are not native UIButton objects. There is nothing “native” in React Native.
Also, the single threaded model of JS just does not scale. The larger the app gets, the more and more it starts to lag. UI is rendering at 60 FPS, sure, but the lag comes from a constantly busy single JS thread.
And that’s before mentioning things like accessibility, large type support, basic iOS concepts such as margins and layout guides, etc. that are sorely missing from RN.
“I want to learn how to fly a Cessna where should I start?”
“I’d recommend hang gliding. That way, you don’t have to worry about the complexities of piston engines. Since you already know how to fly a kite, you’re practically there already.”
While hang gliders and Cessnas are both flying, there are a lot of things Cessna can do that hang gliders can’t.
I will be glad when JavaScript stops being the answer to every question. iOS apps aren’t just webpages running on a phone. How, for example, does react handle pre-release Apple APIs? How does it work with ARKit or other iOS specific tech?
Why do we insist on building to quite literally the lowest common denominator rather than building to the strengths of iOS and Android?
React Native could be a prudent choice for certain kinds of apps, but I’d argue that the apps for which React Native excels probably don’t need to be apps in the first place.
Apps ought not be glorified web pages; they should take advantage of the hardware to the fullest extent.
If an actual Swift developer recommends React Native, I might listen, but generally it’s web developers who downplay the advantages of Swift because they themselves have been unwilling to learn how to get the most out of it and the iOS APIs.
This whole cross-platform obsession results in lower quality applications. Case in point: Slack for Mac OS. It’s decent, but it would be significantly better if it were actually native. This trend of wrapping a webpage and calling it an app is a disservice to your customers.
There’s a reason I have an iPhone. Yet, with this cross-platform nonsense, developers are essentially kneecapping our devices. This applies to Android as well.
I evaluated react native and I really like what I saw and was on the edge to use it. BUT, I am still afraid that it will bite me somewhere in time where it will hurt much. For example, I want to build an app with 50% standard interface stuff and about 50% custom, with some animations throughout the interface. From what I gathered reading other people experiences it would be a bit of a pain in react native.
And the other smaller reason is that I want to build native macOS app that goes along with it and as far as I can tell from my own experience, only natively written apps feel good on osx. And just don`t mention Electron, I hate it.
I think it is best to write the "core" of your application using a language that can run on all of your target platforms -- which typically means you'll have to use C/C++/Rust or something similar that can be compiled to native code and supports somewhat sane FFI. The UI for each platform should be done using the Native UI toolkit for the platform. That way, you can avoid most of the code duplication.
If you plan to target Android, you might want to check out Google's Java to Objective-C transpiler[1]. That will let you write the core of the app in Java and transpire it to Objective-C for iOS and macOS. The UI will still have to be written using the native toolkit for the platform, though. Fair warning: I have no idea how good or bad it is -- never used it myself.
React-native animations have come a long way. I think your concerns are real, but you'd be pleasantly surprised. You might want to dip your toes, see how far you get in a day and how it feels.
IMO flutter.io looks a lot more promising (navigation isn't a mess, for example) but really native is the way to go. I'm biased towards native as that's what I do day to day.
React Native is more fun to work with than PhoneGap though (I've shipped apps with the latter and really hated it).
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?
Swift 3 was a major backwards-incompatible change. It came with an automatic migration tool, but the tool only kind of worked.
Swift 4 is a much smaller change. There are backwards-incompatible standard library changes, but not on the scope of Swift 3. Again, it comes with an automatic migration tool. I haven't tried it myself, but I'm optimistic that it will work much better, both because they've had a year to fix what went wrong the first time, and because the changes are much much smaller.
But Xcode 9 also supports Swift 3.2, which is the same language as Swift 3.1 with some miscellaneous bugs fixed and with the iOS 11 / macOS High Sierra SDKs. Your Swift 3.1 code will likely run under Swift 3.2 with no changes, and any changes that are necessary are going to be strictly due to SDK changes rather than language changes.
Xcode 9 also supports mixing Swift 3.2 and Swift 4 modules. You can have your application written in Swift 3.2 and use a library written in Swift 4, or vice versa. This means you have a full year to migrate to Swift 4 (since I assume Xcode 10 will drop Swift 3.2 support, though this is pure speculation).
The Swift 4 compiler has a Swift 3.2 mode that is 99.9% source compatible with Swift 3.x. Further you can link 3.2 and 4.0 binaries together. This allows a phased upgrade approach that was not possible in earlier releases.
Swift 5 is about having a stable binary interface so you can link against pre-compiled code going forward. In other words a Swift 6/7/8 binary can link against one compiled with Swift 5.
The bar for source breaking changes is also much higher than the already high bar in Swift 4. We may not see any source breaking changes in Swift 5.
I get that they're the same command-line tool, but as a bystander that doesn't tell me whether it's implemented underneath as two separate incompatible compilers that are toggled between with a flag. And even if it's a single compiler with mostly shared components, that doesn't have to imply that the binaries that are produced are ABI-compatible between the two. I'm not implying that I cannot believe that this use-case will work, only asking for some assurance from the compiler devs that it does.
-swift-version 3 really just turns on some different paths through the parser and type checker to allow previously-valid Swift 3 code to survive to code generation time.
Swift has a clear policy on this, but basically: it's worth breaking things early on rather than freeze in bad design decisions. They provide a code migrator to help with this pain.
However, this was only in the early releases. The plan is to stop breaking changes soon and freeze the ABI. They're a little behind schedule for this, but it should happen soon.
> First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a requirement of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer.
> ...
> Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.
>In Swift 5, [ABI stability] is a requirement of the release.
Once Swift 5 comes out, does that mean it's "safe" for people to write things in Swift?
My company still has apps stuck on Swift 2.x because we simply can't give people the time to fix the hundreds of issues that happen when we try to upgrade the project to Swift 3. Unfortunately the migration tools just don't work and we end up having to either fix almost every line of code or revert the repo. Everyone is frozen on a specific version of Xcode as Swift 2.x isn't supported anymore. It's a complete mess, and hearing year on year "this is the last time we'll break everything" is getting very tiring.
For a variety of reasons we're likely to rewrite our app in the coming months. I'm very seriously considering pushing for writing it in Objective-C because it's just more stable than Swift. We can't do a yearly rewrite, especially as mobile is going to be a bigger focus for us this year and next year.
Can you promise me if I push for the rewrite in Swift 5 it will be the last time we need to do that (for a reasonable amount of time, say 5 years? Or that changes will be far far more gradual and can incorporate it with our workflow?).
If not, we're going to abandon Swift because it's already left a horrible taste in our mouths.
> Once Swift 5 comes out, does that mean it's "safe" for people to write things in Swift?
It means it's "safe" to ship binaries to people without providing the source and it should remain compatible forever™.
> It's a complete mess, and hearing year on year "this is the last time we'll break everything" is getting very tiring.
Swift 3->4 was much easier. Of course, if you're still stuck on Swift 2 this isn't going to help you much…
> Can you promise me if I push for the rewrite in Swift 5 it will be the last time we need to do that (for a reasonable amount of time, say 5 years? Or that changes will be far far more gradual and can incorporate it with our workflow?)
That's how it was supposed to be in Swift 4, and it should get better from there.
No, of course not. The way I see it, Swift is scared to go the "Java" route where backwards compatibility is valued above all else, leaving the language an antiquated mess.
You don't have to "rewrite the app". You run the migrator, then fix up what it didn't migrate.
Swift 3 was notorious for having migrator issues, largely due to the fact that it was a pretty radical change and a huge number of method names were changed.
Personally, on our hybrid app, the migrator did about 1/3rd of the work, and I did the rest, without any other engineers' involvement. Overall it took maybe 3 days to migrate the whole app.
It was a way of talking. I said it that way because the migration to swift and from swift 1 to swift 2 we had the double of developers for iOs than Android and still have to wait for them because of so many issues they were having.
Seems like things are not that bad now. But stills scares me that with every new version you lose a developer for some days (or weeks).
The whole 1.x to 2.0 stretch was a rough ride. I had to maintain software without From 2 to 3 was pretty OK since very little changed in the language only API's got updated. From 3 to 4 mainly adds stuff and doesn't break much.
It really doesn't take all that long. I've migrated apps consisting of 20K-30K lines of code in a couple hours–mind you, many of the changes were not due to Swift 4, but those in the Cocoa/Cocoa Touch Swift overlays.
I said to swift, I meant from objective-c to swift. And also from swift 1 to swift 2, where problems weren't only the language but the apis an integration with the old objective-c library. I doubt it takes a couple of hours do that stuff (hour project was close to 100k lines, to one day for you), but If it really takes you that short time companies are going to fight hard to hire you!
Xcode has a migration plugin that's not too bad. The biggest changes are generally for the better so I'm like meh. It's kinda annoying if you have dependencies but maintained dependencies generally migrate very quickly.
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.
I've recently started to investigate web frameworks for swift, and specially the concurrency part. So just to clarify something : current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads.
This type of model is fine and has worked quite well in the past. It is not event loop like node, nor light threads ( like go), nor actors like erlang, but it does work fine. And since swift is fast, it'll probably work just a fine as your python / ruby / node backend.
What we're looking for for the future of swift is something better / safer than that. But my personnal conclusion is that it shouldn't prevent you from building regular webservice api with this language.
> current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads.
Imho that's just the description of event loop(s). There's a central queue, to which you post work (e.g. in the form of function objects or closures), which will get dequeued and executed in a serialized fashion. The thread look like while ((func = dequeue()) != null) { func(); }. That's the event loop.
The difference to node is that you have multiple of these event loops, which are referred to by queue name. In javascript there's only one single implicit loop. If we look at javascript which webworkers we also get multiple loops and queues (one in each worker). However those are more strongly isolated (no shared memory) than eventloops in multithreaded environments.
How much work is expected from the developer point of view? I'd love to have an alternative to Go, but no concurrency for me kills Swift right of the gate for server stuff.
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.
It's not just about a framework. Some marketing/evangelism is needed. Those factors were major contributors to the rise of Go.
And the Swift community itself needs to work on making it officially available on more platforms. Officially, the only non-Apple platform that is supported is Ubuntu -- not Linux, Ubuntu. It runs on other distributions, but having “official” support for more platforms would be a big step towards acceptability. Most people I've talked to still consider Swift on Linux an experiment. Even C#/.Net Core seem to be more popular on Linux.
Having Windows support would make the language more acceptable by cross platform developers -- leading to more high quality libraries being written.
Hey, I'm using Vapor (in production). It's really great to work with and moving fast - feels like the early days of rails. There's a real technical advantage to having the brevity of swift (like ruby) but with the type checking of the compiler. I actually migrated this app from Node.js and it's faster and easier in almost every way (notably lack of 3rd party libraries).
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.
This cliche statement feels trite for such a large project. I'd understand it for a 1000 line JS library, but it makes no sense for a complex language ecosystem that requires multiple full time engineers to maintain.
It isn't my intention to sound "trite". I've personally contributed a little bit to Swift. You don't have to be a compiler genius to help out - you can contribute to Swift Foundation which is almost entirely Swift code and would directly improve cross-platform support.
I would also note that saying "I wish more effort were being made" is a bit entitled when you're talking about an open source project. No one working on any open source project owes you anything. If you want the project to get better then find a way to contribute.
> I would also note that saying "I wish more effort were being made" is a bit entitled when you're talking about an open source project. No one working on any open source project owes you anything.
no, "i wish" just means "i wish". it doesn't imply anything like "being owed".
being "open source" doesn't establish carte blanche to oblige everyone to labor on the project if they dared to have a thought or opinion.
> If you want the project to get better then find a way to contribute.
there are thousands of projects i'd like to see get better. not everyone has the time, ability, desire or capacity to implement everything they've ever wished for. this is just silly.
I am talking about "official" support here. Enterprises are not going to risk using an unofficial port. And unless there is a large scale adoption, it will become another niche language which only the enthusiasts would care about.
More importantly, it needs to happen while Swift still has momentum. Once a language gets old enough, it builds a certain kind of reputation. Once that happens, it is almost impossible to introduce it into new domains.
You can take a look at what IBM has been doing in this space, but in general I'm not sure what you are asking for. Do you expect Apple to release a fully-baked Windows port?
It's a free project that is open-source. Cross-platform support will come from contributions by individual developers, testers, and documentation writers, or companies who find some strategic value in supporting it.
Sitting back and saying "I wish" seems a bit entitled, no? I'm not being glib, I really am saying if you want to see better Swift support on platform X then start contributing. Swift Foundation needs help filling out implementations on Linux and Windows. For the more adventurous you can contribute directly to the standard library or compiler.
Since when did wishing for something mean someone is entitled to something?
“I wish it would stop raining.”
“I wish they'd launch it soon.”
Do any of these statements mean the speaker is entitled to something? Since when did wishing for something become a bad thing?
I am not expecting Apple to release anything. I am hoping for swift.org to one day proclaim that the toolchain and the libraries are available on Windows and other platforms. What I am expecting Apple to do is get behind its own language. I mentioned in another post in this thread -- it is not just about technical work. A lot of it has to do with marketing/evangalism. While individual contributors can help, it takes the backing of large company to get something adopted at a large scale. Why do you think Go succeeded while languages like Nim, D etc are not being adopted as well? What I expect from Apple is to spare a couple of people for the purpose of giving talks, writing blogs etc in addition to working on Swift -- something like what Rob Pike et al have been doing for Go. From what I understand, Apple writes a lot of their backend stuff in Java. Perhaps they could start investing in Swift on server side and open source some of the frameworks/libraries they come up with?
> I really am saying if you want to see better Swift support on platform X then start contributing.
I want to get Swift adopted at my workplace for the next project we are working on. I should tell the management I'll start working on it as soon as I get Swift ported to the platform I use. It would go down really well.
What makes you assume I am not contributing in whatever way I can?
> You can take a look at what IBM has been doing in this space, but in general I'm not sure what you are asking for.
IBM has done some good work, alright. But they are the only ones. A lot more work is required If Sipwift were to become a mainstream language.
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 :)
I already use Rust for some stuff, but Rust and Swift don't compete in the same domain -- despite some overlap. Rust is more for Systems Programming whereas Swift is geared towards Application Programming. Of course, you could use them in each other's domains, but there will be challenges.
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.
I've been using Swift for a few months and really want to like it. That said, breaking down to unsafepointer for newbie tasks is unacceptable IMHO. Try to do basic stuff like TCP/IP socket coms without a third party library or heck, just get the IPv4 address of your network interface.
I assume, they mean that you don't need to have C at all. See how Go for example doesn't require C on most platforms to make syscalls (IIRC, the exceptions are Windows and Solaris).
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)?
The Swift 3->4 migration was not bad, actually–just a couple of small changes to source here and there. With ABI stability I think we'll see the adoption of Swift for libraries and frameworks increase significantly.
I started out building prototypes with Swift 2. The migration to 3 caused a few headaches for me, and some migraines for others it seems. 3 -> 4 was relatively simple. Though, my experience was far less involved than those depending on Carthage/CocoaPods packages.
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.
This is different. COM apartments were a runtime mechanism to magically make the code to run on a single thread (or on multiple but specific threads for MTA), by introducing object proxies that "transparently" marshaled calls.
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"?
I'm still in the process of figuring how that would work. But mostly it would look something like annotation
@threading("BACKGROUND_WORK_QUEUE_A")
func someWork(data) {}
and you wouldn't be able to directly call someWork() from requestHandler() directly, but calling someSubWork() from someWork() would be fine.
The idea is that i've observed that my code could often be split into parts running in their own threads, and the complex thread splitting code would be at the junction.
Adding annotation like that would help me make sure that a function designed to run inside some part wouldn't accidentaly be called directly from another part.
I am not a Swift expert, can you explain your point. How would that situation compare to say programming in Go where there is built-in support for channels, and concurrency?
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'
