mnvrth

I'll suggest giving it another shot. It really is a game changer (I can't tell what you're doing wrong, but in a few people I've seen it has been about doing a psychological switch. I wrote about it a bit here - https://mnvr.in/beginners-mind, sharing in case it helps you see how you might approach it differently)

> Anyone else find where they are doing anything iOS specific to enable background uploads when you don't ever open the app?

Search for "SyncService.instance.sync" in the code, that's what gets triggered.

The trigger is us sending periodic silent pushes to wake up the app.

> My guess is that as part of the Ente team, you open the app semi regularly, which is enough for the device to give some budget for your cloud sync process to kick off in the background every now and then.

I know what you think, but that's really not the case :) Many our customers are on iOS, they're satisfied with it. There are areas to improve yes - the initial import is the major pain, esp because it is also the customer's first interaction with the app - but the background sync itself is works seamlessly in practice.

Yes, the app does iOS background sync. Many of us (I'm part of the Ente team) are avid users and have a huge photo libraries, and day-to-day, it works seamlessly. We don't need to reopen for it to sync etc. The only time one needs special care is when doing the initial import - at that time, we sometimes need to keep the app running in the foreground for the initial sync to complete.

As the other commenters are mentioning though, this is all black magic at the mercy of Apple. The way we've evolved with our code works now, but who knows what future updates to iOS bring. One thing we've observed that it takes sometimes like say seven days for Apple's on device ML to pick up that the user really wants to use the app, and convince the OS to allow the app to run in the background to sync. But again, this is not something we've needed to worry about as _users_ - we just use it normally as we'd use Apple Photos, and it just works after the initial sync completes.

+1 for your invocation of eldritch gods :)

I know what you're saying, there is undoubtedly a complexity angle too, not all of it is malice. But after a while, one starts noticing the pattern (or maybe it is just me) that Safari has a holier-than-thou attitude towards standards. Their way of standardization is - I'll just go ahead and do something my own way, and then rest will just follow suit because I have so much market share.

Which isn't, as you say, far from Chrome's actions in theory. But in practice, the feeling I've been getting recently is that more Chrome is happy to accommodate. Safari seems to (intentionally or culturally) drag its feet a lot more in picking up stuff that has been ratified.

This is beautifully put! I hope more people are able to understand the point you're making, especially how "having a globally accepted standard for anything is a unique and historic achievement".

> I think this is beautifully written.

Thank you! I'm so happy that what I wrote other have found beautiful to read :)

I believe that there is too much negativity going around, and I try my best to nudge things in a positive direction, and reading your comment I feel happy that it now that is also being reflected in how I write.

Thank you for the comment! Much appreciated :)

I feel sad that you feel like that, because it really isn't! Of course, different things work for different people, and you and I just might have different ideas of fun, but for me it's the opposite. I find great joy in writing web code.

I will give it to you though - the ecosystem is complex. It takes a while to figure out what works for oneself and what is just chaff. And there is a lot of needless complexity.

Anyways, my point here is - do try to give the web another try. Maybe it'll click, and you'll start having fun writing code knowing that you can send a link to anyone and they'll be able to enjoy what you've created irrespective of what device they're on, and instantly.

OP here. Funny you mention Shoutcast, because a Shoutcast player is what I'd made earlier - https://github.com/mnvr/Soundtrack. So I sort of know what you mean :)

And you know the reason why it's macOS only? because the Apple App store reviewer rejected it heh.

Wow, that's a great way of putting it! Thanks, I had never linked the dots that way before.

I would second that. Frameworks are secondary. React + TypeScript was the key (for me at least). After that it is just learning web standards - starting with CSS, HTML, JS - and then moving on to Canvas, WebAudio etc if one desires.

I didn't move from Google because of this bug. I'm just using that bug as a (pretty symptomatic) example.

Thank you! :) What has really made me happy recently is realizing the web now has at-par capabilities, and I can make all sorts of cool AV stuff that works straight out in the browser. It's heady really, the possibilities, I'm excited to learn more and make more of these.

Thank you for saying that! Such feedback is very encouraging, much appreciated :)

This was super helpful and easier to understand than the wiki page. Thanks for taking the time to writing these!

Interesting! I'm curious, are there examples of the non-promissory estoppel that could give me an idea of what those look like?

Nothing like that! This is just a genuine TIL post :)

Author here. We were reviewing our legal docs today. It was just a word that I found interesting. I wrote about it. That was all.

I agree, scaling support is a hard problem. But Google has set an extremely low bar, they've just given up, and they can just blatantly do that, because of their effective monopoly/duopoly.

I'm sure we (if not us specifically, some other project like us) can do better.

> How does this prove Data security?

You're right, that by itself doesn't prove data security. But what we try to do is follow the example of other privacy-first Google alternatives like DDG, Signal, and try to structure our organization/processes/code in a similar way.

> Any white-paper?

https://ente.io/architecture/

Not quite a white paper, but I feel https://ente.io/architecture/ covers the practical aspects of what we do in a human readable way (we wanted this page to be understandable by people with a non-cryptographic background, I'm just mentioning the intended audience, a few of our customers have reached out to us and have mentioned they found it useful too).

(Disclaimer: I'm part of the crew building https://ente.io)

I hope someone at Google takes a look at this and uses their internal tool to help OP.

That said, this oft repeated story is one of the most compelling reasons why I think Google alternatives (like the one we're building) will catch on in the mainstream population. Not privacy. But the fact that we offer human support, whilst Google doesn't.