The product expectations here are: - After the transition, no new features will be backported to Objective C to be used on iOS 6. All new features will be developed in Swift. The exact feature cut-off is to be defined by product and design (setting up a meeting about this tomorrow). - Crash fixes and major bug fixes will continue to be handled on the iOS 6 version for the mid future (e.g. next few months). - Code will be refactored from Objective C to Swift as time allows, e.g. possibly as an onboarding task for new engineers. There will be no planned effort in the short- or mid-term (e.g. next few months) to refactor old code from Objective C to Swift, although this is the plan in the long term.
Let me know if you need more, or need any clarification. Dan On 13 November 2014 13:35, Tomasz Finc <[email protected]> wrote: > 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/Swift_Programming_Language/TheBasics.html > [2] - > https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/Migration.html > [3] - > https://trello.com/c/dgYqIuId/21-spike-hr-determine-whether-we-re-ready-to-migrate-to-swift > > On Wed, Nov 12, 2014 at 10:05 PM, Dan Garry <[email protected]> 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 > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
