My Adventure With Swift, Xcode And iOS

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.

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)

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.

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.


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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jozsef Torsan

Jozsef Torsan


Founder & software engineer. Creator of the Bookmark Ninja online bookmark manager.