Local Native iOS v0.4.1 发布, with SwiftUI

prelude

It has been another few months since last Local Native v0.4.1 release, which was not able to include iOS version due to crashing in TestFlight. Now iOS v0.4.1 is finally released!

the bug?

I still could not identify how the crash occurs by staring at the crash log.

the fix.

It turns out the fix is to rewrite iOS code in SwiftUI.

Fortunately thanks to existing solutions for data flow, search bar, QR code, hiding keyboard, the rewrite is very pleasant and code becomes more concise by removing storyboard and view controllers.

One thing maybe a drawback from previous iOS version is that the bookmark note text is not selectable.

Local Native v0.4.1 发布, without iOS, yet

prelude

It has been a few months since last Local Native v0.4.0 release, which introduced (wireless) syncing via tarpc, database schema change and more. That is decent amount of internal data structure change and observable new features. Everything was well and I was not worrying about rushing out more features very soon, until ..

the bug.

In contrast, this v0.4.1 release is only motivated by fixing the one observed bug:

the touch input keyboard for the share extension's text fields (tag and description fields etc..) does not show up in iOS, after upgrading to newer version (iOS 13.2.2 as of writing). This prevents user to input tag or description, or change title or url for the note.

Saving note still works, but what's the fun if I can not add tags to a note?

Technically This is a new feature only in newer version of iOS. How hard could be

the fix?

Local Native v0.4.0 发布

As hinted in the previous post, this v0.4.0 release is a MVP to show sync between different devices using slightly patched tarpc . Currently sync works between desktop and desktop, desktop and mobile when they are on the same LAN/WiFi.

The schema of note table is updated to have an extra uuid column to uniquely identify and dedup records for sync. At the end of sync operation, both devices will end up with same set of uuid by appending the diff from the other device.

Mobile device can scan a QR code encoding the server address and port to connect to the server to start sync.

iOS sync screenshot:

Add uuid4 and tarpc in Local Native

uuid4

I have not cut a release yet, but the work-in-progress Local Native v0.4.0 introduced a new uuid4 field into note table.

Why?

This serves as a unique key for each record, syncing between different devices could leverage this new column. Actual code for syncing is still yet to be written. The idea is uuid4 could be used as a record identifier to compare with records with other devices.

I considered using key based on actual content, but decided that's too much and preferred true randomness.

Local Native v0.3.8 发布

localnative-desktop-v0.3.8.png

What is new?

  • This Local Native release marks as a personal milestone to satisfy my day-to-day use case for web bookmarking and note-taking with title, URL, tags, and description.
  • Search, create, read, delete and pagination are implemented for desktop (gnu/linux, mac), browser extension (firefox, chrome/brave) and mobile (ios, android).
  • On desktop, time-series charts are shown to allow filtering on time range, and tag cloud is visualized.

Why Local Native?

It seems applications today are "Cloud Native" by default. For end user, it becomes expected for a "meaningful" application to have all its data available on all the devices all the time. However this assumed convenience comes with drawbacks:

  • performance for certain feature

Network is still slow, hence caching and syncing cache with remote datastore is a normal practice to boost user experience at the cost of draining device battery.

What if things are stored locally natively?

When I was implementing the type ahead search for Local Native App, a brute force database query upon every keystroke just worked. Scaling issue seems goes away if you do not need to deal with network latency and multiple users competing with each other for CPU. I start to appreciate how fast the hardware becomes today.

  • your data is on someone else's server

Enough said about privacy (freedom) concerns.

I used to have tens of social media profiles out of curiosity to checkout "what's on the internet". Util time itself becomes increasingly limited resource, and I figured most of the time I just need a bookmarking tool for the internet, so I can go back to something quickly, and maybe also run some SQL against those url and tags myself.

What if things are stored locally natively?

Without a traditional remote server, syncing across devices does become a challenge, but opportunity may lie here as well. Local Native App currently is able to sync via ssb, with some serverless setup first.

Toolchains today seem are all for centralized services, but 15 years ago where are those toolchains for modern mobile and web apps?