Apple's Swift language project gains continuous integration

Posted:
in General Discussion
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.

Comments

  • Reply 1 of 15
    Is this CI for the users of Swift -- i.e., developers who are writing programs using XCode -- or is this CI for the people who are modifying the Swift language itself (Apple employees + participants from the Open Source community)?  I think it's #2... which is good but applicable to a fairly small audience.
  • Reply 2 of 15
    Is this CI for the users of Swift -- i.e., developers who are writing programs using XCode -- or is this CI for the people who are modifying the Swift language itself (Apple employees + participants from the Open Source community)?  I think it's #2... which is good but applicable to a fairly small audience.
    It's for the language itself. But I am curious why Apple isn't using the Xcode Server feature in OS X Server. Does Apple even use OS X Server themselves?
  • Reply 3 of 15
    I think it's the latter. Only 21 pull requests, 336 commits by 58 contributors. Even so, it's a very good thing. While I have no plans to contribute (full time Java enterprise dev and doing my first Swift app on the side), I've got the repository up and visited daily...
  • Reply 4 of 15
    freerangefreerange Posts: 1,597member
    Non-programmer asks, "does making Swift open source create / increase future security risks / problems"? 
    edited February 2016
  • Reply 5 of 15
    ksecksec Posts: 1,569member
    I believe Swift 3.0 will be big this year in WWDC, and will be big in OSX 10.12 as well as iOS 10.
  • Reply 6 of 15
    freerange said:
    Non-programmer asks, "does making Swift open source create / increase future security risks / problems"? 
    Yes and no. It potentially surfaces security risks earlier. But it also provides a huge pool of talent to find/review/correct those situations. Also, Swift is not the OS - it is a language. It isn't so much security issues as it is buffer overruns and other memory shenanigans - which Swift is designed to make inaccessible. Most security issues would IMO be from linking in libraries/frameworks written in C/C++/Objective C...
    Rayz2016SpamSandwich
  • Reply 7 of 15
    mjtomlinmjtomlin Posts: 2,673member
    freerange said:
    Non-programmer asks, "does making Swift open source create / increase future security risks / problems"? 

    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.
    cornchiphmm
  • Reply 8 of 15
    auxioauxio Posts: 2,717member
    mjtomlin said:
    freerange said:
    Non-programmer asks, "does making Swift open source create / increase future security risks / problems"? 

    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.
    As long as there's one or more knowledgable people closely reviewing all of the changes going in, then no, it doesn't increase risk.

    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.
  • Reply 9 of 15
    It makes no sense to build a 32 bit runtime for Swift. Everything moving forward's baseline is 64 bit.
  • Reply 10 of 15
    Unless Apple mainlines Swift inside of LLVM it will fail to achieve wide use. It has to compete with the Go Language from Google and others as a first tier support or it won't go anywhere.
  • Reply 11 of 15
    They have already announced the ABI will be stable for Swift 3.0.  The real question is if the next round of OS updates will start to include Swift shared libraries or if they will hold off for another year.
  • Reply 12 of 15
    Unless Apple mainlines Swift inside of LLVM it will fail to achieve wide use. It has to compete with the Go Language from Google and others as a first tier support or it won't go anywhere.
    I don't see that being an issue.  Anyone deploying on a server will use prebuilt packages and will not care about that.  I definitely see something like node.js (likely even based on the node.js backend) coming out targeted at App developers since their appears to be a lot of demand for it with multiple groups working toward this.  I don't think Go is mainstream enough to worry about competing with.  Swift is more pragmatic then Go.  So Go might be better in some niches, but Swift is better suited to take market share from existing languages.

    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.
    edited February 2016
  • Reply 13 of 15
    auxioauxio Posts: 2,717member
    Unless Apple mainlines Swift inside of LLVM it will fail to achieve wide use. It has to compete with the Go Language from Google and others as a first tier support or it won't go anywhere.
    Maybe we're in the minority, but for those of us working on native, cross-platform, GUI applications (not web-based or server-side apps), Go isn't even on our radar.  Then again, because Swift only runs on relatively modern OS X, iOS, and tvOS systems, it's not really either.  But it stands a better chance of getting there.
    edited February 2016
  • Reply 14 of 15
    mattinozmattinoz Posts: 2,299member
    So what if there was a Swift App library that did work cross platform would it be more interesting?

    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.
  • Reply 15 of 15
    hmmhmm Posts: 3,405member
    freerange said:
    Non-programmer asks, "does making Swift open source create / increase future security risks / problems"? 
    You can locate potential vulnerabilities by looking through source code, but more people looking at it means it's more likely to be patched. It is more likely to be a net benefit to security.
Sign In or Register to comment.