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 <dga...@wikimedia.org> 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 <dga...@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 >> > > > > -- > 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