Apple's Swift language project gains continuous integration
Apple on Monday officially launched continuous integration for Swift, enabling checks on the project's health, and integrated testing within pull requests before any commits are made.
Apple's system is based on Jenkins, and builds and runs tests for OS X and the iOS simulator, as well as Ubuntu Linux, according to the official Swift blog. It's designed to allow more configurations over time, "especially in the cases where ports to other platforms or architectures reach a critical mass and support from the Swift development community," the Swift team said.
If a developer makes a change that breaks a build, they'll automatically receive an email notification. The project should soon start supporting performance tests as well.
Swift is a relatively young programming language, as even Apple itself is believed to be making little use of it outside of a few mobile apps and small sections of OS X El Capitan.
There's still no 32-bit Swift runtime for OS X, and the Swift ABI (application binary interface) is unfinished. The latter, at least, may arrive alongside Swift 3, but Apple is unlikely to reveal any detailed plans until June's Worldwide Developers Conference.
Apple's system is based on Jenkins, and builds and runs tests for OS X and the iOS simulator, as well as Ubuntu Linux, according to the official Swift blog. It's designed to allow more configurations over time, "especially in the cases where ports to other platforms or architectures reach a critical mass and support from the Swift development community," the Swift team said.
If a developer makes a change that breaks a build, they'll automatically receive an email notification. The project should soon start supporting performance tests as well.
Swift is a relatively young programming language, as even Apple itself is believed to be making little use of it outside of a few mobile apps and small sections of OS X El Capitan.
There's still no 32-bit Swift runtime for OS X, and the Swift ABI (application binary interface) is unfinished. The latter, at least, may arrive alongside Swift 3, but Apple is unlikely to reveal any detailed plans until June's Worldwide Developers Conference.
Comments
One could argue that a "hole" could be created in the compiler, but the fact that it is open source also means that everything is exposed to peer review and any such issues would be discovered and fixed by others. It would be virtually impossible to sneak any such code into the project without it being detected.
That said, all of the open-source evangelists who maintain that OSS makes things more secure are missing the fact that, in either case (open or closed source), there can be people who independently find security holes and sell/exploit them without reporting them to anyone else. Perhaps open source projects can respond to such situations sooner (depends on how good the project maintainers are and how quickly they can distribute fixes to the people who use their software), but it doesn't eliminate the risk completely.
One can argue that, in the case of software designed for end-users who don't have the ability to rebuild their own software, the effectiveness of the software distribution mechanism to get new versions of software out to people as quickly and easily as possible is the most important factor. You can fix security holes in the source code as fast as you like, but if the vast majority of end-users don't know how to update their software, then it doesn't matter.
I think the only way it will be mainlined is if LLVM moves away from C++ and toward Swift for its implementation. Swift will need to become much more performant for that to happen and will probably need C++ interoperability. Swift wants to be a good systems programming language eventually but initially they are focusing more on making it good for App development. Sort of the opposite priorities of the Rust language. I could see it happening eventually, but not for at least 5 years.
Say Apple makes a iCloudOS in the Web browser using a webAssembly Swift runtime and standard library.
Apple gets to sell developers hardware by tying it to xCode running on a Mac.
Apple gets users to sign up to iCloud accounts with the hope of selling them hardware.