Working Copy: a brief review
Hi frens,
One of my goals of developing Defensive Security is to sign the commit message for proof of authenticity. On regular git repository, only integrity of the code base is guaranteed, not the git author. The author name or email isn’t verified at all, which means anyone could commit and pretended to be someone else or anonymous.
On the iOS platform, while we couldn’t have a nice terminal and Git support, Working Copy has been the most popular Git client since launching in 2014, bringing simple signing commits feature. However, the iOS platform has evolved for years just for the filesystem experience to be acceptable.
MacStories has a comprehensive review of how iOS has been a mess for different apps co-working on the same file, and how Working Copy has been keeping up every new system feature.
There are several ways of iOS apps co-working on files:
Use iCloud Drive or Files app to share file or folders (since iOS 11).
Open the document in other app, without duplicating it (since iOS 8).
Use share sheet but actually duplicating the document into another app (since iOS 3.2).
With Pro Unlock (35.99 USD), the Working Copy experience should be as simple as “link external directory” from Swift Playground, sign commit with SSH key, and push to remote repository.
I managed to have a workaround to run the flow without Pro Unlock:
On Working Copy, initiate new repository. This will create a folder with .git directory in it.
On Files app, copy Swift Playground project into that folder.
On Swift Playground, open the project inside Working Copy folder, and develop on that project afterwards.
From now on,
Sign commit with GPG key on Working Copy.
Push to remote repository by... copying the folder to a computer, and let the computer do the job! LOL
It also shows how awful the iOS filesystem experience could be, and seamless developer experience relies on Pro Unlock of Working Copy.
Your friend,
Denken