@Mhurd I'm interested in participating to this task. Do you have any suggestions on what file/class to begin with?

@julbod Oh great thanks!!

I'd recommend starting with some of the simpler Obj-C "category" methods. I find it convenient to just use a "+" in the filter to see all category files:

I'd suggest...

• a separate pull request for each conversion to ease the review process
• if you're converting a method which doesn't already have test coverage the first commit should probably add a test file with a few tests of the method(s) being converted
• use cool Swift things like "guard" statements, etc. The project is Swift 3 compatible!

For example, if I were converting the "NSCharacterSet+WMFExtras.m" category:

• I'd create a branch called something like "Swift:NSCharacterSet+WMFExtras"
• my first commit would add a "NSCharacterSet+WMFExtras.swift" test file with a few tests. These tests, written in Swift of course :) will need access to the Obj-C method(s) being tested (until conversion is complete) so you'd have to add "NSCharacterSet+WMFExtras.h" to the "Wikipedia-Bridging-Header.h" file
• my next commit would do the conversion ensuring all tests were still passing. It would also delete the NSCharacterSet+WMFExtras.h and NSCharacterSet+WMFExtras.m files and remove the line added to the bridging header.
• hopefully at this point the conversion is complete and the app actually still works ;)

For the moment I would avoid converting:

• anything which is tricky to test - i.e. requires complicated mocking, visual tests, etc
• anything in the Xcode "Legacy" group since these are scheduled to be refactored away
• complicated objects, view controllers etc. we'll eventually want to deal with these, but there's so much low-hanging fruit to pick first
• NSURL categories - there are bridging issues we're still trying to figure out how to best handle.

Thanks again for the interest and help!!! It's very much appreciated.

Feel free to ping me if you run into any issues or have any further questions.

One other thing to keep in mind:

There are sometimes subtle (and not so subtle) user-facing bugs which can crop up with conversions even if unit tests pass, so expect there may be some delay and/or rounds of testing and feedback before proposed conversions are merged.

Limiting conversions to less complex category methods, as suggested in the comment above, will help, as will keeping pull requests as atomic as possible, but feel free to ask first before beginning any conversion to confirm it's a good candidate in the first place.

@Mhurd

I'll be attending the Hackathon, and am interested in learning a lot when I'm there.

This seems interesting yet not too scary for me too hop on. However, I've never written anything in Objective-C or Swift, so do you have any tips for setting up a development environment and learning the languages? (Setting up the iOS app as well, and learning how to test and use it properly when developing) Also, are there any example patches for such things described in the task? (Is this on gerrit or Phabricator)

Thanks!

@MtDu Hi I'm sorry I missed your comment! Unfortunately I had an injury a couple months ago and wasn't sure my tendon (Achilles) would be healed enough by the time the hackathon was happening so I ended up not being able to attend :(

Regarding setting up the iOS app, the readme.md at here has instructions to get you started. For good resources for learning Swift and legacy Obj-C this site is pretty great!

Obj-C's learning curve is unfortunately a bit high (which makes having Swift all the more nice) and some of its subtleties may be tricky to navigate as a beginner, but even if converting Obj-C to Swift ends up being too tricky I'd highly recommend learning Swift and following its (open source!) evolution here. Swift's support for protocol oriented programming in particular is pretty interesting. This video lays out the concepts and this one explores the concepts further.

I hope this helps and again apologies that I can't make the hackathon! Super bummed :/