Thanks for kicking this off Dan. I've been following Swifts development from the sidelines and I'm eager to put it through its paces. Given that modern iOS releases can support hybrid Swift and iOS apps, the risk of experimenting is low and potential pay off is high. Addressing some of the questions I've gotten. = Existing Engineers = I expect all of our engineers to be well rounded and exposed to multiple languages. This means picking up new languages as necessary for their job and anticipating future platform changes that require new expertise. Swift is just another one of these. While jumping between some languages can be a huge leap, Swift is not. The language [1], migration [2], and iOS/OSX integration are well documented giving me confidence that we have the resources to move forward giving our current resourcing. = Team Growth = I expect no significant change to recruitment in the short term 6month - 1year. I expect a significant difference in the 1yr - 2yr range as more people come up to speed and have built real world applications with it. Thus I anticipate and huge help in hiring in the future with this change. I do expect more volunteers experimenting with our code base if its swift based and I know that we have internal non app staff who are curious to join these efforts. I can easily see a 1day hackathon centered on helping us get to swift pulling in various resources. Next step will be to define a spike to assess a migration. [3] Dan, i'll need you to define what this migration means to product if we decide to go forward. Product needs to define what features will be frozen, what if anything need to be backported, and which iO6 bugs we will respond to. --tomasz [1] - https://developer.apple.com/library/ios/documentation/swift/conceptual/Swif… [2] - https://developer.apple.com/library/ios/documentation/swift/conceptual/buil… [3] - https://trello.com/c/dgYqIuId/21-spike-hr-determine-whether-we-re-ready-to-… On Wed, Nov 12, 2014 at 10:05 PM, Dan Garry <dgarry(a)wikimedia.org> wrote: > tl;dr: The programming language used to develop new features by our iOS > app > engineering team is changing from Objective C to Swift at some point in > the > near future. > > When making a native app, the language you have to implement the app in > is > chosen by the third party responsible for the platform. For iOS apps, > Apple > chose Objective C to be the language the app is written in. Objective C > is > a... very strange language. It has a lot of quirks that slow down > development. > > To solve the above problem, you can now write apps in a new language > called > Swift. Notably, Swift has features that make it less error prone and > more > concise than Objective C, which should increase our velocity of feature > development. Swift is also much more readable and in-line with other > languages, which lowers the barrier of entry (which is currently very > high > with Objective C). > > Importantly, Objective C and Swift can live alongside each other. So, > when > we "switch to Swift" we do not need to rewrite all of our existing code > from > Objective C to Swift. Instead, we can just start developing new > features > using Swift, and slowly rewrite the old code from Objective C into > Swift as > time allows. > > On the downsides, Swift is only supported on iOS 7 and above. iOS 6 > only > represents around 5% of our user base, and we can pin iOS 6 users to > the > last version of the app we released before we used Swift. We need to > decide > what the last set of features we're want in that build are before we > switch. > > Here are our next steps: > > Evaluate more concretely whether Swift actually fits our needs or not. > [Engineering] > Decide last set of features for our iOS 6 build. [Product/Design] > > Thanks, > Dan > > -- > Dan Garry > Associate Product Manager, Mobile Apps > Wikimedia Foundation > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l >