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.

Advertisements

22 comments

  1. Sounds like a frustrating few days/weeks Jozsef but a sensible conclusion there…! I’ve experienced a fair amount of subjectivity in App store reviews, for example, having the same app accepted first time round and then rejected after being resubmitted with a minor bug fix. We sorted this by providing a more detailing explanation to the reviewer in the submission notes. May be worth testing out the limits in future on this one.

    Liked by 3 people

    1. Hi Liam, a friend of mine told me exactly the same story that you wrote about (Apple accepted their app for the first time, then rejected it for the second time…) It doesn’t seem to be a unique case. It’s also about luck who does the review at Apple. Fortunately in the short term I have some ideas how to proceed without having a native iOS app but still providing a good user experience. But sure, in the long term I will get back to the iOS app idea.

      Like

  2. Xcode definitely took me some time getting used to as well. I’m finally at the point now where I’ve learned which bugs are due to Xcode and which bugs are self-inflicted haha 🙂

    Liked by 1 person

  3. I,too, encountered some difficulties when I started to develop in Swift. I got used to the Swift syntax’s easily enough, but you are right: the backward compatibility issues are more than slightly annoying:-(
    Despite that, I like Swift: like any other programming language it has its good points, and its bad points, but once you get used to it you can develop native apps quite quickly. I just hope that Apple keeps polishing the rough edges that Swift still has.

    Liked by 1 person

    1. Sure, I agree, it’s really a question of time to get used to the syntax of a programming language. And it can be difficult if you’ve already spent much time with another language. Regarding the backward compatibility issues I hope it will improve, Swift is still a young language, it changes rapidly.

      Like

  4. And supports C# and JavaScript for languages. You can create the GUI in code or via the 2D IDE very quickly. From the same codebase and project you can deploy to iOS as well as Android as well as Window, Mac & Linux should you need that as well. It is used by game developers because it was designed for it but I found that there is functionally little difference between a 2D “game” vs a 2D “app”. Just my 2 cents 🙂

    Liked by 1 person

    1. Hi Joy, as far as I know you can’t build an extension app on iOS with any of the mobile cross platform frameworks. What I wanted to create was a share extension app not just a simple app. In case of a share extension you have to write native Swift code (for example 15 lines of code were required to get the url/title of the web page – it’s crazy…) Anyway I will take a look on Unity 3D, it seems to be a cool framework. Thanks for your tip! 🙂

      Liked by 1 person

      1. I know you can extend Unity with native code extensions however I have never tried myself however there is a large developer community around Unity in the for of the asset store where free and paid assets are available. Additionally developers frequently publis bbq to Github as well. Not sure of this will meet your needs but I did locate this: https://github.com/ChrisMaire/unity-native-sharing/blob/master/README.md sounds like it might be what you are looking for and it’s licenced under the http://www.wtfpl.net/ licence so it’s essentially your code if you want it and it works. Let me know if you have any trouble testing it 😉

        Liked by 1 person

      2. Thanks so much for all the info you sent me, I really appreciate it! I will check them when I get back to my iOS project. This week I start coding some new features for my web app, that will improve the user experience. These are kinda higher priorities than the native iOS app. Thanks again for your help, Joy! 😉

        Like

    1. Hi Mike, I’ve heard about React but haven’t looked at it yet. Thanks for your tip! I will check it when I get back to my iOS project. Now I’m back to the Java development of my web app, there are some higher priority tasks that have to be done. Thanks again! 🙂

      Like

  5. Just my 2 cents 🙂 In case of a ploughshare extension you accept to drop a line native Swift codification (for model 15 lines of codification were required to arrest the url/statute title of the entanglement page – it’s crazy…) Anyway I will make a feel on Unity 3D, it seems to personify a coolheaded theoretical account.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s