Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS
Team, all of these features on the tip of master already except disambiguation and page issues, which is slated for the upcoming two week sprint 55, starting Monday, 13-April-2015. The hope is that at the end of sprint 55 we'll have a release candidate that will be the final version supporting iOS 6, but it may be at the end of sprint 56 (i.e., submission in the first couple days of sprint 57) if necessary. In any event, this should provide plenty of runway to add the Swift bridge in time for the Lyon hackathon. -Adam On Thu, Jan 29, 2015 at 2:14 PM, Dan Garry wrote: > I'm necroing this thread so that our new engineers can see it. > > The product expectation is that we drop new feature development for iOS 6 > when the following features are in production: > >- Lead images > - Wikidata descriptions from mobileview >- Search improvements > - Supplement prefix search with fulltext search results > - Wikidata descriptions from PageTerms >- Read more > - Three suggestions from fulltext search backend at the bottom of > every article >- Collapsing tables and infoboxes >- Rollup disambiguation and pages issues into buttons underneath the >lead image > > Dan > > On 12 November 2014 at 22:05, Dan Garry 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 >> > > > > -- > Dan Garry > Associate Product Manager, Mobile Apps > Wikimedia Foundation > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS
I'm necroing this thread so that our new engineers can see it. The product expectation is that we drop new feature development for iOS 6 when the following features are in production: - Lead images - Wikidata descriptions from mobileview - Search improvements - Supplement prefix search with fulltext search results - Wikidata descriptions from PageTerms - Read more - Three suggestions from fulltext search backend at the bottom of every article - Collapsing tables and infoboxes - Rollup disambiguation and pages issues into buttons underneath the lead image Dan On 12 November 2014 at 22:05, Dan Garry 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 > -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS
On 13 November 2014 19:10, Tomasz Finc wrote: > 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. Given that the goal is for you two to both switch over to Swift and be able to do code review for each other, I second that. I copied the card, and assigned one copy to both Brion and Monte. Two hours each! I leave it to you two whether you want to actually spend that time side by side, or whether you want to just sync up afterwards. Whatever works best for you. Dan ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS
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 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 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 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 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
Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS
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 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 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 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
Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS
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 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 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 > > > >
Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS
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 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@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS
Being able to use Swift will be a huge benefit! It lowers the bar for volunteer contribution - Obj-C is pretty tough to wrap your mind around as a beginner. Obj-C code also ends up being *much* more bloated than Swift code, making it even harder for volunteer contributors to grok our Obj-C code base. Being much more concise and generally less clunky than Obj-C is great, but Swift also has baked-in protection against entire classes of errors common to Obj-C, and TONS of time saving and powerful modern language features. So, yes, Swift a.s.a.p. please! On Thu, Nov 13, 2014 at 3:21 AM, Joaquin Oltra Hernandez < jhernan...@wikimedia.org> wrote: > Swift is a very interesting language, should be exciting! > > On Thu, Nov 13, 2014 at 7:05 AM, Dan Garry 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@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > ___ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS
Swift is a very interesting language, should be exciting! On Thu, Nov 13, 2014 at 7:05 AM, Dan Garry 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@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] [Apps] Using Swift for new feature development on iOS
*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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
