- Swift 4.2 Download
- Swift Coding
- Swift Programming Course
- Swift 4.2.1 Xcode Version
- Swift 4.2
- App Development With Swift
Swift 4.2 is now officially released! Swift 4.2 builds on the strengths of Swift 4, delivering faster compile times, improving the debugging experience, updating the standard library, and converging on binary compatibility.
![Apple swift classes Apple swift classes](https://i.ytimg.com/vi/5pv_KHpG71w/hqdefault.jpg)
You can watch a quick overview of it by watching the WWDC 2018: What’s New in Swift presentation, and try out some of the new features in this playground put together by Ole Begemann.
04 September 2019. Objective-C-to-Swift converter-as you type. Follow this app Developer website. ISwift is the easiest way to convert your Objective-C code to Swift. Ultra fast: Automatic as-you-type conversion, so. Swift is a powerful and intuitive programming language for iOS, macOS, tvOS, and watchOS. Writing Swift code is interactive and fun, the syntax is concise yet expressive, and Swift includes modern features developers love. Swift code is safe by design, yet also produces software that runs lightning-fast. 1.25e-2 means 1.25 x 10-2, or 0.0125. For hexadecimal numbers with an exponent of exp, the base number is multiplied by 2 exp: 0xFp2 means 15 x 2 2, or 60.0.
Language updates
Swift 4.2 is a major language release and contains the following language changes and updates that went through the Swift Evolution process:
Generics improvements
With the completion of conditional conformance support, Swift 4.2 makes significant progress in implementing the vision of generics in the language. Better support for generics ultimately reduces the amount of boilerplate needed in your code and make more of your code reusable. To learn more about conditional conformance, see more at:
Watch the Swift Generics WWDC 2018 presentation for more details.
Standard Library updates
The standard library in Swift 4.2 includes a number of new features, including improvements to the Hashable protocol as well as a new unified set of randomization functions and protocols.
See more at:
Binary compatibility
Swift 4.2 brings the language closer towards a stabilized ABI, enabling binary compatibility for future releases of Swift. Visit the ABI Dashboard for more details on the current progress of this effort.
Additional language and compiler updates
Swift 4.2 includes a number of improvements that have a noticable impact on developer experience, including:
- Support for batch mode compilation resulting in faster build times
- Change in calling convention for retain/release cycle to reduce code size and improve runtime performance
- Lazier SIL deserialization with -Onone
- Recursive metadata support
- More compact reflection metadata
- Default arguments are inlined at call sites
- Some long-standing bug fixes, including init declname, switch with multiple case labels per block, inheritance of generic initializers, and more
Swift 4.2 also implements the following language proposals from the Swift Evolution process:
- SE-0054 Abolish ImplicitlyUnwrappedOptional type. Read even more details about the reimplementation here.
Package Manager Updates
Swift 4.2 introduces new features for the Swift Package Manager:
- Support for batch mode. Swift targets will be now compiled using the Swift compiler’s batch mode.
- Automatic Xcode project generation. The generate-xcodeproj has a new –watch option to watch the file system and automatically regenerate the Xcode project if needed. This uses the watchman tool to watch the required files.
- Improved scheme generation logic. The scheme generation logic is improved and generates schemes as follows:
- One scheme containing all regular and test targets of the root package.
- One scheme per executable target containing the test targets whose dependencies intersect with the dependencies of the executable target.
Swift 4.2 also implements the following Package Manager proposals from the Swift Evolution process:
- SE-0201 Package Manager Local Dependencies. SwiftPM now supports declaring dependency on a package using its path on disk instead of the git URL. This requires updating the package’s tools version to 4.2.
- SE-0208 Package Manager System Library Targets. The PackageDescription API in tools version 4.2 supports a new type of target “system library target”, which moves the current system-module packages feature from package to target level.
- SE-0209 Package Manager Swift Language Version API Update.
swiftLanguageVersions
property in PackageDescription manifest API for tools version 4.2 is changed from an array of Integers to an array of SwiftVersion enum.
Migrating to Swift 4.2
Swift 4.2 is source compatible with Swift 4, Swift 4.1 and Swift 3. Swift 4.2 will be the last release to provide source compatibility with Swift 3.
To help with moving to Swift 4.2 from earlier releases of Swift, Apple’s Xcode 10 contains a code migrator that can automatically handle many of the needed source changes. There is also a migration guide available to guide you through many of the changes — especially through the ones that are less mechanical and require more direct scrutiny.
Documentation
An updated version of The Swift Programming Language for Swift 4.2 is now available on Swift.org. It is also available for free on the Apple Books store.
Platforms
Linux
Official binaries for Ubuntu 18.04, Ubuntu 16.04 and Ubuntu 14.04 areavailable for download.
Apple (Xcode)
For development on Apple’s platforms, Swift 4.2 ships as part of Xcode 10.
A toolchain is also available for download from Swift.org.
Sources
Development on Swift 4.2 was tracked in the swift-4.2-branch on the following repositories on GitHub:
The tag
swift-4.2-RELEASE
designates the specific revisions in those repositories that make up the final version of Swift 4.2.The
swift-4.2-branch
will remain open, but under the same release management process, to accumulate changes for a potential future bug-fix “dot” release.Swift 4.2 improved the
Hashable
protocol to make it faster, simpler, and more secure, all at the same time. If you currently generate hashes by hand you will almost certainly want to migrate to the new API, but even if you don’t you might still find the behavior of your code changes.Hashable
is one of Swift’s most important protocols, but it often goes unnoticed. You use it every time you create dictionaries or sets, for example, because those types create hashes of your data to figure out where it should be stored.Swift 4.2 Download
Before Swift 4.1, conforming to
Hashable
was complex because you needed to calculate a hashValue
property by hand. In Swift 4.1 this improved so that hashValue
could be synthesized on your behalf. So, it turned this kind of code:Into this:
However, if you wanted your own hashing implementation – for example, if your type had many properties but you knew that one of them was enough to identify it uniquely – you still needed to implement a
hashValue
method using whatever algorithm you thought was best.Swift 4.2 improved this situation further, thanks to its implementation of SE-0206: Hashable Enhancements. This introduces a new
Hasher
struct that provides a randomly seeded, universal hash function to make all our lives easier.If you’re just relying on automatic synthesis of
Hashable
your code won’t change at all, although the end result might – more on that later. However, if you’re generating your own hashes then your code gets a lot simpler:You can also use
Hasher
as a standalone hash generator: just provide it with whatever values you want to hash, then call finalize()
to generate the final value. For example:Note: You must not call
finalize()
if you’re writing a custom hash(into:)
method for your types.SPONSORED Ever ask for help and your reviewer immediately notices issues you missed? Fernando Olivares is a 10-year veteran from Big Nerd Ranch and Lambda School who can help hone your app building skills, and he's just launched a new book that does just that – use the code 'hacking' to save $5!
Hash flooding and you
Now, all this might seem academic because the end result is a hash value integer just like we had before, but there is one important difference that might break your code: the
Hasher
struct uses a random seed to generate its hash values, which means that a given object’s hash value will change between runs of your program.Random hash values are an important feature, because having a predictable hash value gives a potential opening to attackers. In particular, there’s a well-known attack called hash flooding: if I know your hashing algorithm ahead of time, I can easily generate a lot of different objects that have the same hash.
Swift Coding
It’s helpful to look at a real example, albeit a deliberately simplified one. We might decide that our
Jedi
struct should be hashed based just on someone’s name, like this:An attacker could look at that code and realize they can generate any number of Jedi objects using the same name and a different
darkSideUsage
property. These objects are unique enough to added multiple times to the same set or dictionary, but similar enough to generate the same hash.For example:
That will generate 100 Jedi called Obi-wan Kenobi, each with their own random
darkSideUsage
property.Now, this matters because of how sets and dictionaries work. It’s a common misconception that hash values must always be unique, but that isn’t the case – it’s strongly preferable that they be unique, but sets and dictionaries are perfectly capable of holding two different objects that have the same hash value.
In our case, we just inserted 100 unique Jedi objects with the same hash value – I did a quick benchmark, and it took 0.002 seconds on my MacBook Pro. But what if were to insert 10,000 elements in the set – how long would that take?
You might guess 0.002 x 100, i.e. 0.2 seconds, but you’d be wrong: it actually takes 1.92 seconds. And inserting 30,000 of these objects takes 21.48 seconds – that’s 11 times longer for 3 times the objects.
A regular set or dictionary has O(1) look up and insertion, which means it can insert new objects and find them again at a constant speed regardless of how many objects you insert. Here, though, we have flooded our set with identical hashes – hence the name “hash flood attack” – which means that the O(1) behavior is no longer possible, and instead we get O(n²) performance. This is what causes the massive time lag: the set can no longer insert objects quickly because they collide.
Now imagine someone inserting 100,000 pseudo-identical objects – this is the kind of thing that could crash Swift apps or take down Swift-based web servers. This is one of the problems that Swift 4.2’s
Hashable
struct solves: it uses a pseudorandom function called SipHash that was specifically designed so that attackers can no longer predict what the hash value for a given object will be ahead of time.Now that you understand the basics of why hash flooding is dangerous, I want to give you a slightly more real-world example so you can see the threat is real.
After a busy day of using the force, Jedi naturally want to go home and watch Netflix just like everyone else. So, we’re going to update the
Jedi
struct so they have an address:As you can see, that generates the hash value for the Jedi using their name and each of their address properties.
However, that hash algorithm is trivial for attackers to flood: they can just create
Jedi
instances with the same text strings in different places, like this:Pomodoro timer windows. That first Jedi uses 1, 2, 3 for its first three address values, the second uses 2, 1, 3, and the third uses 3, 2, 1. Because the actual data being stored is the same, the hash value will also be the same – it doesn’t matter that they appear in different properties, because
a ^ b ^ c
yields identical results to c ^ a ^ b
.With seven string properties there are over 5000 such combinations of our properties. If you use eight properties for your hash there are over 40,000, and if you use ten you’ll have over 3.5 million – all trivial for attackers to figure out, because it’s just using the same strings in different places.
The new
Hasher
protocol avoids this by maintaining a hash state. This is why you generate hashes using a combine()
method: each time you add a new property into your hash, it’s combined with whatever the previous state was, ensuring that the order you add things matters.So, we could rewrite our hashing code to use the new Swift 4.2
hash(into:)
method, like this:And now each Jedi will generate completely different hash values even though the strings they store are the same.
Swift Programming Course
Side effects of randomness
As you’ve seen,
Hasher
introduces a random seed every time it hashes an object. This change means the hash value for any object is effectively guaranteed to be different between runs of your app.The documentation for the
Hashable
protocol has always warned that this might be the case:Swift 4.2.1 Xcode Version
Hash values are not guaranteed to be equal across different executions of your program. Do not save hash values to use during a future execution.
Swift 4.2
In Swift 4.2 and later this is now definitely the case, and this has an important side effect: elements that you add to a set or a dictionary are highly likely to have a different order each time you run your app.
Now, realistically you should never have relied on sets and dictionaries having the same order between runs, but if you did then now is the time to update your code.
That being said, you can force Swift to use predictable hashing for testing purposes only: set the environment variable
SWIFT_DETERMINISTIC_HASHING
to 1, and Swift will replace its random hashing seed with a constant value. This will not work in production, but it could in theory be helpful for some very specific tests.If you’re excited by the
Hasher
struct, you should read my article detailing all the other new features in Swift 4.2 – there’s a lot of them!App Development With Swift
SPONSORED Ever ask for help and your reviewer immediately notices issues you missed? Fernando Olivares is a 10-year veteran from Big Nerd Ranch and Lambda School who can help hone your app building skills, and he's just launched a new book that does just that – use the code 'hacking' to save $5!