Since we're following a similar offline-first model as in the desktop client, we probably want both a sync indicator and the ability to cancel syncs. This isn't a priority, but cancelling might have an effect on sync architecture, so worth keeping in mind. (In the client, I just set a cancellation flag when the cancel button is clicked and check for the flag at various points during the sync — beginning of each object download batch, etc.)

I'm not sure whether we care about sync progress. In the client we can show progress info on sync button hover, so if we want that here we'd have to use a different sort of indicator, but that might be unnecessary.

All screen should have a dark mode alternative.

Redesign login screen with the possibility to register a new user.

Maybe we already have this, but if not, we need to make sure that a 5xx response for any HTTP request always retries on a backoff schedule — otherwise we'll end up DDoSing ourselves as more and more clients fail.

(I noticed this in the retryInterval in SchemaController. In the desktop client, the API client automatically retries after 5xx errors on a backoff schedule, such that the calling code doesn't have any knowledge of the 5xx unless a maximum number of retries is reached. Since a 4xx should fail permanently and a 5xx should be retried automatically, the calling code shouldn't need to bother with a retry interval.)

https://gist.github.com/dstillman/51cf1e1b91e61e12e480117925bed772

It looks like we're supporting Dynamic Type in some components (e.g., the collections tree) but not others (e.g., items tree). We should make sure we're supporting it everywhere.

Currently, the items list isn't refreshed until the whole sync process is done. We should refresh throughout the sync, though we have to balance responsiveness and performance.

In the client, I increase the refresh batch size as the sync goes on for a smoother start:

https://github.com/zotero/zotero/blob/ad27e0c5faed8eaa939ab6e40dfce95c1eefb2ad/chrome/content/zotero/xpcom/sync/syncEngine.js#L596-L613

So the first 10 items appear immediately, and then batches of 5 up to 50 items, and so on. We don't have to do exactly that here, but we should make sure there's immediate feedback as new items (and collections, for people with thousands of collections) come in.

I just see a paperclip icon for all attachments, with no titles shown.

For beta:

• design a search functionality - possibly a simple search input field above each list (items/collections)
• implement a simple search functionality to search for keywords in local DB

For full release:

• show searches in collections/libraries
• finish proper search syncing
• implement search filtering functionality

Review and redesign the item detail/creation/editing screen if needed. Things to review:

• can editing/creation stay like this or do we want to split it from the detail
• layout
• icons, colors, fonts and sizes
• visible fields and other data
• attachments:
  • showing of existing attachments
  • downloading of attachments - not downloaded/in progress/downloaded states
• notes:
  • showing of existing notes
  • adding/editing new notes - javascript html editor or other input methods
• tags:
  • showing of existnig tags
  • adding new tags

Implement new iOS 13 API so that users can have multiple instances/windows of our app opened.

Review and redesign the collection creation/editing screen if needed. Things to review:

• icons, colors, fonts and sizes
• layout
• parent collection picker

Implement support to drag and drop in our app. Review what we want to enable to be dropped into our application (text, images, pdfs, ...).

Review and redesign the collection list screen if needed. Things to review:

• icons, colors, fonts and sizes
• the ability to create a new collection
• the ability to edit or delete a collection

Do we want to show a sync progress anywhere? Where and what do we want to show if yes. Where do we want to show the sync button with the ability to start new sync or cancel current sync.

When an item doesn't have a title, tag circles are being shown larger than normal.

Review and redesign the item list screen if needed. Things to review:

• icons, colors, fonts and sizes
• layout and visible/missing info
• the ability to create a new
• the ability to delete an item

This special collection should only exist for personal libs.

The setting is lost when I tap away from a view.

Implement filtering of items in "My Publication" section in library.

It seems like right now it's just showing a circle for every tag, rather than just colored tags.

Some features are already mentioned in #5 and #33. Do we want to support other accessibility features, for example voice over?

Search conditions have a fixed order that needs to be maintained on edit. Unless I'm just missing it in Realm Browser, it doesn't seem like an order is currently being stored.

Implement a PDF reader using PSPDFKit, including proper annotation functionality (including #38).

Right now trying to open a PDF that fails to download (e.g., because it's not available online) still opens the PDF reader. It should just show an alert that says the PDF isn't available. Not quite this, but same idea:

https://github.com/zotero/zotero/blob/89992665cd456b452cd92dd702d6eed3acbef67b/chrome/locale/en-US/zotero/zotero.properties#L369-L371

Design and implement an onboarding screen for new users.

Design and implement a settings screen.

Localize the app into all languages that MacOS app supports

Searches should sync after collections, before items

Before opening this up, we'll need to add an AGPLv3 license file and note in every file that it's AGPL licensed. (In the meantime, there's no need to add "All rights reserved", which doesn't mean anything anyway.)

Render notes as HTML and extract plaintext through either the first newline or some number of chars (whatever a reasonable max might be in landscape), and then store in a separate column for display and sorting.

Try to port the iPad app to MacOS Catalina.

Rewrite the existing RxSwift code to Combine. Low priority.

Implement a way to manage tags (create, delete, choose color). Implement a way to filter by tag(s).

I'm not seeing anything about conditional requests in the schema-update code.

This should use standard conditional HTTP requests. When bundling a version of the schema, the ETag should be stored somehow (perhaps as a property that's added to the JSON?), being careful to use the same Accept-Encoding: gzip header that's (hopefully) used later. Later requests should send the ETag in If-None-Match, such that, most of the time, clients shouldn't ever get anything other than a 302, even in a new installation. If a new remote version is ever available, the ETag should be stored again.

When I start the app, I'm in My Library, but I still see the library list in the left pane. It should instead show collections for the current library.

Along the right-hand edge of the table view, as in the iOS contacts view and various other apps.

Not sure if there's a standard or popular open-source control for this, but ideally it would also be able to handle other field formats so that we could use it if, say, you were sorting by date. (I feel like I've seen that on iOS, but not sure where. I think I've seen it with years shown in the control, but with a month overlay in the middle of the screen as you move through the dates.)

Right now, if you scroll down to the middle of the items list while new items are being pulled down, the list will start to jump all around as items are added.

There's no perfect solution here, since the items you're looking at may not remain contiguous, but we could maintain the position of the first fully visible item in the current view, which should generally result in a fairly anchored view. If that item is removed from the view, we'd have to go with the next item in the list, which would take its place.

Similar to #6, creators assigned to items have a specific order. Maybe I'm missing something, but I'm not seeing that in the DB.

Rewrite the UI layer (and partly data layer) to SwiftUI.

Implement a way to sync pdf annotations

I would recommend against using the group id as the primary identifier, with -1 for personal. It's not guaranteed that there won't be multiple personal libraries in the future, and there could be non-group library types we'll want to support later. (E.g., in the client we have feed libraries.) Not sure how Realm works, but if it should be an integer of performance, I would assign a local auto-incrementing library id, which is what we do in client and server. If the DB uses some other internal integer regardless, it could be something like L1 (for personal library) and G1234, where 1234 is the remote group id. [That's a dumb idea. Don't do that]

Add CI processes for running tests for each commit/pull request. Add automated builds for internal, public beta testing and releases.

Implement the websocket observing of remote changes

Beta: all conflicts are resolved by using remote version.

Full release: Implement proper CR and diffing. Either by using existing javascript code and JavaScriptCore or by reimplementing the whole CR in Swift.

Currently, items without data are shorter than other rows.

Implement filtering of items in "Duplicate items" section in library.