Excellent. I'd even take it one step further and have *both* you and brion take on this spike so that the whole team gets exposed to it. Thus both of you take the 2 hours to research this. This could be together or totally separate. Each one has pros/cons.
--tomasz On Thu, Nov 13, 2014 at 7:01 PM, Monte Hurd <[email protected]> wrote: > With Tomasz I added a new Swift spike to the iOS board: > https://trello.com/c/3jKbmL0z/22-spike-2-hour-convert-at-least-5-single-method-categories-to-swift > > Basically it's a dry run to convert some of the most simple code in the app > codebase to Swift to see what issues we encounter and give us a rough > baseline for how quickly existing code can be converted. > > The spike should not be considered to signify the moment we officially fork > the code (with the pre-Swift base being maintained only for iOS 6 bug > fixes). Timing for this forking should be informed by what we learn during > the spike and Dan will make the call as to when we fork. > > When we do fork and enable Swift for ongoing development, I do not think we > should necessarily immediately switch all development to Swift. My > preference would be to switch completely to Swift over the course of a few > months as we gain experience and mastery of it. We may find this doesn't > actually take months, and I suspect it won't, but I would prefer to ease > into it. > > Does this sound ok? > > > > On Thu, Nov 13, 2014 at 1:45 PM, Dan Garry <[email protected]> wrote: >> >> 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 >> > _______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
