press ‘1’ to see who said what

Do we want Shortcut Actions?

Do we want a universal App? One app for iOS, iPadOS and macOS.

Do we want Widgets?

What should the share sheet look like? What should it be able to do?

What requirements does Pirijan have?

What are we going to do about subscriptions?

Should we bridge the native iOS haptic feedback API to JS? (like on FL)

Does the Kinopio API token expire?

quick add ideas to inbox (similar to the browser extension)

quick open your fav/pinned spaces

both. the widget lets you type something yourself to save

shared txt/url/img added as an inbox card

I can provide a querystring, that’ll hide upgrade and pricing mentions for v1

That could work. Alternatively, the app could call a JS method on window after it finished loading.

the main thing is that kinopio urls open in the same webview, and external webviews open in either another webview or system browser (which you think is best)

So it would open a native sheet inside the app? This native sheet could also be used as the share sheet.

yes i would love this, is it possible for the app to emit postmessages (or whatever) whenever it wants the device to vibrate/haptic? eg when opening a card

does this mean that the sign up/sign in for the webview is done outside the webview? or that there’s a seperate flow in either case, having a seperate login flow may be a maintainance issue?

All links to kinopio.club should open inside the app and all other links should open in the default browser.

is it possible to open an ‘alert prompt’ style dialog that doesnt need to wait for the app to open to receive input?

Yes, I set this up for Futureland. After it’s bridged you can just call a method like this.$iOS.onSoftImpactFeedback()

Yes it would be outside of the webview. And yes that would be more maintenance. An alternative could be to send the token to the native part of the app via an JS bridge. Maybe like this.$iOS.setToken()

From the widget, no. But it shouldn’t take long to open the app and show a sheet.

On the iOS Home Screen app there’s a white area above the webview (where the notch/island is). Can I postmessage a background color to it?

if/when the web client adds offline/manifest support, will that automatically add offline support in the same way to the ios app?

i like the latter idea more. is the js bridge just a postmessage?

I need to research this first. I didn’t know Safari already supports this.

if the user opens a kinopio.club link in their email or from elsewhere, is it possible to open up the native app with the same url if the native app is installed (kinda like what the twitter app does?)

I tried this using DuckDuckGo on iOS and it lets me reload PWA while I am completely offline. So this should work.

Haptic Feedback API

On iOS safari when focusing on a text field the view pans and zooms on its own and can’t be overridden. Can that behaviour be disabled in a wkwebview?

I tried this inside the WKWebView now, and it works on iOS, iPadOS and macOS. So getting the offline PWA to work should be enough.

api.kinopio.club

I have a kinopio apple developer account. Can I share the credentials with you so you can submit the app as kinopio?

Not sure how zooming on Kinopio works right now, but could you consider using the following meta tag? <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=0, minimum-scale=1.0, maximum-scale=1.0"> This fixed this issue for the FL app.

Yes! All links with kinopio.club will automatically open in the Kinopio instead of the default browser.

The repo for the IOS app can be open source. I can either invite you to the kinopio GitHub org or to the repo

WKWebView (kinopio.club or index.html)

Instead of sharing the credentials, invite me as a developer with admin permissions for the Kinopio app.

That is up to you.

would love to contribute to this project :D

re offline/index.html bundling: any places you could point me towards how to add support for this?

I had a normal npm run build in my mind, which creates the whole app + index.html as entry file. But I forgot that routing on kinopio.club works via URL. It’s probably not the best approach for this. Currently I assume that the PWA approach with offline web workers make the most sense for you.

do the webworkers handle routing or do something else specific? or are the webworkers are just there as part of the PWA spec?

They are just part of the PWA spec. I would assume you don’t have to change routing at all.