My Adventure With Swift, Xcode And iOS

Bookmark Ninja is a web app, it runs in the browser on both desktop and mobile. On mobile devices it has a mobile dedicated web UI that looks like a native mobile app. In desktop browsers it uses bookmarklets and browser extensions that make possible to send the current web page link to Ninja. On mobile currently you can do this only with sending the link via email to a dedicated email address (tap on share then select email). But with this solution you are not able to add tags or to set the destination Tab/Category what you can do in the desktop browsers with the help of the bookmarklets and extensions. So it was time to find a better solution for the mobile browsers. The ultimate solution is a native mobile app which is actually a share extension app for the mobile browser.

Plan A

The original plan was to develop a full native iOS app that communicates with the Ninja server through RESTful api. 3 years ago I learned about REST when I took the Java classes, but I have never worked with REST, I have zero experience. Also introducing REST impacts the server side too, not just the client iOS app, so there’s going to be even more work to be done.

The other challenge is Swift. 5 years ago I started to develop an iOS game in Objective C. I worked on it for a year part time. Then I gave up, I didn’t finish the project. I also remember that I was not a big fan of Objective C and Xcode. I read that Swift has many improvements over Objective C, so I was really looking forward to get familiar with Swift.

Plan B

Plan B came into the picture, when I started to worry about the amount of work this project requires, especially considering the uncertainty with REST and Swift. My idea was to simplify the things with having a webview in the iOS app. In the webview you actually access the Ninja server through https just like in a browser and the UI looks like a native mobile app (using PrimeFaces mobile/jQuery mobile). With this solution I can win the following things:

• No REST is required at all because I access the server in the webview through https
• Have to write much less Swift code (all the “add bookmark” functionalities are covered in the webview, already developed in Java)
• User authentication also can be done in the webview (already developed in Java)

I thought it was an awesome idea, so I decided to go with plan B. It took only a few days to implement the iOS share extension this way. I could save a lot of time with plan B, so I think it was a good decision.

Still not a big fan of Swift and Xcode

Although it really took only a few days to code the share extension, Swift and Xcode were disappointments. After Java and Eclipse programming in Swift with Xcode felt like riding a bike backwards. I can’t explain better what I felt but I think some of you might know what I mean. I would like to mention just a few of my experiences:

• I felt that the API support is not really developer friendly. I had to select the share extension target when I created the project. This is about, for example, sharing a web page in a browser. So I thought that getting the title and url is kind of something.getUrl() and something.getTitle(). No, this is not the case. You have to write 15(!) lines of code to get the url and the title. And I didn’t find these 15 lines of code in an official Apple dev documentation rather I found them on the different forums and on Stackoverflow.
• Backward compatibility… When I searched for something on the net most of the Swift codes I found were in either Swift 1 or 2. When I tried to use those functions it turned out that most of them were depreciated, removed or have been renamed in Swift 3. So every year when a new version of iOS comes out I have to update my code, rebuild and resubmit the app?
• I couldn’t debug… Breakpoints didn’t work, “print” didn’t print to the console. I searched the net for this issue, and found quite a few discussions about this topic. I tried everything that were suggested, but didn’t help. Finally added the iOS “tweet” sound effect in the code to check if that part of the code runs or not. Well, not a professional debugging technique…
• I felt the syntax of Swift to be the same awkward as the syntax of Objective C. Ok, I agree this is kind of a personal subjective judgment.

I didn’t dig myself deep into Swift but even with just scratching the surface I ran into many issues. It’s true that I only developed a simple share extension, I don’t have any experience with other areas, they may be OK, I don’t know… Nevertheless I was happy that I could come up with a solution that saved a lot of time.

My happiness didn’t last long

I was pretty happy and satisfied until I started to read about the Apple App Store submission guidelines. It soon turned out that many developers had problems with submitting apps that include a webview. This seems to be a sensitive area and using a webview can be the cause of a rejection. The even bigger problem is that Apple doesn’t seem to like the webview login, they prefer the native login (when login is implemented with native iOS controls). This pretty much sucks… and immediately destroys plan B. And it also means that probably plan A is the only option. Shit.

Conclusion

Going with plan A would mean a lot of extra effort (especially considering what experiences I had with Swift in this short time frame). I already wrote about in one of my former posts about how to decide which features to implement. I think the amount of work that is required to accomplish plan A is out of proportion to the customer value that this new feature would bring in. Also this feature was rather my idea, it was not a request from the customers. There are other smaller features in the backlog, that have higher customer value but require less work. Now I will rather go with them. There is even a small but useful feature that will improve the current “Add to Ninja” user experience on the mobile. And all these features have to developed in Java on the server side. Bottom line is that I decided to postpone the “Add to Ninja” native iOS app. Later when I get back to this project I will probably finish plan B (the webview one) and will give it a chance to submit the app to App Store. But the chance is really low that it will be accepted. So the story is really about plan A. We will see.

I have mixed feelings. On one hand I’m sad because I love challenges and this is definitely a big challenge. On the other hand I’m a bit relieved because I still feel that I’m not a big fan of Swift (Objective C), I prefer Java much more. But now I’m excited that finally I can return to Java next week.