Hello World! I moved my stalled development blog to Micro.blog in the hope to bring this thing back into use after a much too long time! We’ll see…

Papertrail Diary 2

The new .app domains became available this week and of course I was too slow to get papertrail.app. Too bad, but I already knew that I have to find another name at some point to prevent some trouble if I want to bring it to the App Store. I’ll try out some other ideas and see what sticks in my head. I still love the name - it would be perfect - but it’s too obvious for it to still be available.

I started development this week and I’m already stuck a bit. I want the basis to run as soon as possible, but that’s also some of the hardest parts to work on. The internal architecture should be flexible and I definitely want to implement it in a test-driven way. But that also needs some thinking first. It looks simple from the outside but when taking a closer look and if it should be flexible enough to be ready for new features in the future there are lots of different ways it could look like. So, there’s some back and forth with different ideas and I’m not quite sure I’m taking the right path at the moment. I think I need to take a step back and delete what I coded so far to get an unbiased view on the project again.

Some might ask why I want to develop a pet-project Test-driven. It’s simple: there’s no other way for me to develop an app and be confident about my code and that changes don’t break anything. I’m coding on another project at work at the moment and it’s just great to see it grow through the tests. I can make additions and changes and still know that everything works without testing all the other things manually. It’s also satisfying to see the number of tests grow and having all the green checkmarks show up in Xcode. It gives me a great deal of confidence that it’s good what I’m working on. The code I produce that way is much cleaner and easier to understand. It makes you think about how everything works in a totally different way. Another huge benefit is the time I save when I have to fix or adjust some parts that are affected by changes and additions. The time I put into the tests pays off multiple times in the long run. But that’s just my opinion. Others might not want to put in the effort to develop that way. For me it’s the only way going forward.

I’m thinking of putting out some stats every know and then to track the progress. Not sure I’ll stick with it though. Such metrics barely show the real progress, but it’s interesting to see some numbers from time to time. So here’s something for today:

I currently used the Master/Detail project Template from Xcode. It gives you something to start with, although barely anything of the original code will be left at the end. There’s some code in it though, and in order to see how many lines of code I produced I wanted to keep track of the starting point.

4 text files.
4 unique files.                              
1 file ignored.

github.com/AlDanial/cloc v 1.76  T=0.01 s (316.4 files/s, 26497.2 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Swift                            4             78             54            203
-------------------------------------------------------------------------------
SUM:                             4             78             54            203
-------------------------------------------------------------------------------

This is where everything started. Only the actual code of the main app. No libraries or tests included. Let’s see how this will look like in the future!

Papertrail Diary 1

After I created the Xcode project a couple of weeks ago with it’s dependency to a Swift wrapper framework I built for the library I need to use for Papertrail, it took me a while to get back to work. During the last couple of days I mainly thought about how I should tackle the basic UI, how to get from here to there and what possibilities I have. I looked at some other apps and decided to go the straight forward way, not reinventing the wheel. The app will have a standard iOS UI, no custom controls or fancy animations and usage patterns. A stock iOS app.

In the past I started by drawing some sketches of my ideas into a notebook and refining them over time into quite detailed wireframes. I like this approach a lot. First of all it’s fun! By doing this with pen and paper it slows me down and ideas start to pop up while drawing. But it always took me quite some time to finish the wireframe. It’s a great feeling when it’s done, but at the moment I don’t have the time and inspiration to go in to the nitty gritty details. I had a basic flow in mind and wanted to get something visible done quickly. Therefore I turned to Interface Builder and threw some view controllers onto the canvas. A standard Master/Detail app template already provides some infrastructure and after a few hours of moving around and connecting the controllers and adding a bit of boiler plate code here and there, I now have a very basic clickable prototype of my app.

I’m not sure yet whether I’ll stick with the Storyboard or do most of the wiring in code, but I’ll probably just use it. A basic UI without a lot of custom stuff or containers and complex navigation is more or less good to handle. Storyboards have a bad reputation, but they are a very powerful tool to get basic stuff done much quicker than coding everything by hand. There are drawbacks, but they are a non-issue for me right now.

The next step will be to think about how to structure the model and how to architect the code. Also here I won’t do much fancy stuff, without using the current app architecture and tools of the day like VIPER or React. Stock app, stock pattern. Model-View-Controller has proven to be a stable thing and it still sticks around after many years. Also here, it has kind of a bad reputation but it can be clean nevertheless. You just have to be careful. I’ll make it as flexible as possible and needed in case I come up with some more features in the future or want to change the UI at some point. I’ll also have most of the model and non-UI code tested by unit tests, but that’s a topic for another day.

Tranquil and Papertrail

For the start of the development diary for my current pet projects I’d like to introduce you to both of them. I chose two codenames that I really like. If the apps should ever see the light of the App Store, I’m not sure those will stay… but as long as they are living only on my devices, they are perfect.

I won’t go into any details about the features itself though. I want them to stay a little more under the radar. It’s nothing secret or highly important. I just don’t want it to be too public. Those projects are hobbies and I would like to keep it that way. The important thing is that I work on something and create tools that make my life easier. The dev diary part is a companion that might help me keep focused and motivated and also help me to solve some issues by discussing different options and approaches. Sometimes being too vague about the projects will be a stumbling block, I might get more specific then. Otherwise I think there will also be value in discussing some aspects on a broader scale. We’ll see how it will develop.

But now, let’s get to the projects and why I’m working on them:

Papertrail

Papertrail is an app that I desperately need in my daily life. I need one of my favorite apps on the Mac also on my iPhone and iPad. It’s crucial for me, but there is nothing that would even remotely fit my needs. There are a couple of apps available that kind of do parts of what I need, although the features are not 100% there, the usability is horrible and even if a cloud storage provider is supported, it’s only Dropbox. I am living a Dropbox-free life since a couple of years now and having my files on my server is very important to me. This is the key issue with all the other apps. I’m not going back to Dropbox only to satisfy a single tool.

This app will be a very straight forward and simple productivity app. I’m not much of a designer, so there will be no fancy stuff to show off, but using only the available controls and some standard styling will be perfectly fine. It even helps because it keeps the focus on the task at hand. As long as the interaction is intuitive and everything can be done and accessed quickly and easily, there’s no reason to spend too much time on a design that will only make it worse if I do it myself.

I’m using an existing library that helps a lot in handling the data for me. Managing this data is also not too complex. So the main problem on development side will be some things that I did not use at all up until now. Integrating the app with document providers will be by far the trickiest part of the app. It will definitely require some studying and fiddling around for me.

This project has the bigger priority of both projects. I really need it, so I hope to make some quick progress and be able to start using it rather sooner than later.

Tranquil

The second project, called Tranquil for now, is something that I have in mind since a couple of years already. I even did some development for it and when I went into my archives and dug out the code I was pleasantly surprised about how far I’ve gotten already. It was fully functional! All that was missing was some in-app purchase code, a decent icon and design and it could have been a pretty neat app in the store. But I lost focus and even completely forgot about it over time until I recently realized that this thing is still missing for me.

Unlike Papertrail, there is already some competition available for Tranquil. It seems to be a problem for more people than just me. But all the apps do not work the way I want them to work and there’s some stuff missing where I just can’t understand why those apps are missing the key features for their use case.

On the technical side there are some more interesting problems to solve for me. In-app purchase would be the biggest issue, but since I want to build this for my personal use now, I guess this part will be stripped out until I decide to go live with it after all. Besides this I need to do some testing and check whether the system functionality I need to use got more stable over the years. If I remember correctly, the flakiness in that area was also something that kept me from publishing the app in the end. If it didn’t work, it would have seemed like the app is crap whereas the reason it didn’t work was a wonky system feature. I’ll find out soon what’s the status here.

Soon because none of the existing code even compiles at the moment. I did the mistake of coding with an early Swift version. Turns out… current Xcode versions are unable to transform or compile old Swift code. I’m undecided about whether I should just start over or try to make the current code work again. This will probably be the first topic for the Tranquil dev diary.

Development Diaries

I’ve wanted to share some progress about my ongoing projects for a long time. Ever since I read the Diaries1 on Brent Simmons’ blog, providing insights in progress and struggles in his projects as well as valuable advice, I thought to myself that I should do something similar. There will probably be much less valuable advice, but I hope to solve some of my struggles by writing about them.

So… there will be a development diary for my pet projects. There are currently two apps I try to work on whenever I find some time to concentrate on them – which is not very much time, to be honest. I’m not sure if they will ever come to an end and find their way into the app store. That’s one reason why I try to stay a bit vague about what those projects are all about. I will not make a huge effort to keep it top secret, I just don’t want to be pinned down on finishing and publishing and asked about the progress all the time.

There’s a lot more to make an app successful than just the coding and those parts will be the main reason for me to not go into the app store (but that’s a whole discussion on its own). My motivation to build those apps is that I really want them for myself. I actually need them in my daily life, and there is nothing that either works the way I want or is not unusable to me. Those apps sit in a pretty niche market, so I wouldn’t get rich with them… just one more reason to keep everything calm and don’t put too much pressure on myself. But: I also don’t want to be overtaken again by someone who’s working on exactly the same stuff, but has magnitudes of available time more than I do. It’s a hobby and I want it to stay that way. If anyone should find out what I’m working on: congratulations! If not, that’s also fine. It really does not matter at all, but I think there will be enough to talk about in general when working on an app which does not 100% require anyone to know what the app is about.

That’s where I want to go and explore. It’s those parts that are always hard for me and were always a huge demotivation in the past. I’ll try to improve on this front and by asking myself some hard questions and writing about them and the progress I made, it will only help me to go beyond the wall I sometimes ran into in the past. The start will be to write a bit about the first steps for both projects, one of which is already existent since quite some time but needs a major overhaul, and the second one which will be a whole new project for me.


  1. Diaries like this, this and this [return]

Welcome

Welcome to kokodev.de! Yes this is yet another reboot of this site. No this is not a reboot-post. I’m not looking back, I’m pretty much also not looking forward. I just want to make some space for technical stuff I’m working on. There’s not that much to see at the time of this writing, the site is of course pretty much empty, but it’s a work in progress and will evolve during time.

A few weeks back I wanted to get back to work on some pet projects, but there was strong competition in the App Store already for the ones I had in mind and therefore decided to drop the ideas and wait until I find something else. However, I recently felt the need of a certain tool on my iPhone, so I took another look at the competition and decided that they are not what I want. I would have to do it on my own. I’m not going to publicly announce what this is about as of yet, but I want to document the progress and process of me working on it. This will take a lot of time… a lot of time.

If you want to follow me along the journey to get to the finish line – or not, in case I can’t get it to where I want it to be – I would be happy to share this development story with you.

Back to writing, back do coding, back to Xcode!