Everything is moving very quickly, this is just generally the case for anything related to at protocol/bluesky (which is fine, they've been quite busy).
is blueskyweb.xyz an official site for them? I've only seen bsky.social which now redirects to.. bsky.app? (if so couldn't the web stuff live on.. bsky.app?)
edit: bsky.app links to blueskyweb.xyz so I guess so. weird.
The clustering here is really misleading at the higher zoom levels. Shows 100% coverage when you hover on a large area, then you zoom in and find 50% of that same area has zero coverage.
This is huge for me. I went down the path of trying to build an entire API on CF Workers and the biggest stumbling block was no easy access to external relational databases due to a lack of v8 compatible connectors. This was before the D1 announcement of course.
They still require external connections to be made over HTTP and not other networking protocols. This is part of why this new driver is useful. Before today, it would have been impossible to use PlanetScale directly from a worker without it.
I was convinced Apple review guidelines state the core functionality of the app must be in the bundle that is reviewed and they would reject it if it's loaded mostly over http. Can see where they are coming from given they could review the app as a calculator app that then turns into a porn app post review.
Did the author just get lucky with the review process?
I've wondered about this and products like expo 'over the air' updates for React Apps etc. In theory does seem to infringe on these guidelines but are somewhat common in the iOS and Android eco-systems at the same time. I suspect an element of 'Don't ask don't tell' is being played out.
I also recall another guy -- who I think was openly advertising it as way to get around app store guidelines got taken down. JSONRoller or something my memory escapes me.
You can pack the JSON into the renderer if you want. The real meat of the app is the renderer itself, though. For example, you could put the menus and controls in an embedded JSON and then have the app fetch the data view from a server. It's not like your average Twitter or Facebook can show a whole lot without Internet access, so I don't think Apple will reject any apps that don't work without internet access. Add some certificate pinning for good measure and Apple will have to test on rooted iPhone to get access to the data being exchanged, and I don't think the testers really care enough about that stuff anyway. They'll much rather complaintthat you link to your website in a way that angers the Apple gods and other such low hanging fruit.
There are plenty of apps out there that are basically this but with custom logic. Lots of other apps are not much more than a webview with a custom "can't contact the servers" screen.
I suppose it's technically user-generated content, so it's fine? i.e. the app developer couldn't possibly know at review-time what it would be, and that run-time stuff is only distributed (in theory) to the person(s) that generated it; it isn't 'the core functionality of the app'.
I wouldn't be so sure. Ionic has a commercial product, AppFlow, which is their "update over http" solution. It allows for running arbitrary code without app approval, and they claim it is compliant. AirBNB and I'm sure plenty of other companies use "server driven UI" which is similar to this. Almost every app will also use feature flags in some way. Or could even just check if the account is "appreview@apple.com" and show different content, theres not a good way to prevent it.
> Or could even just check if the account is "appreview@apple.com" and show different content, theres not a good way to prevent it.
One would hope they'd do their app testing with regular user accounts designed to blend in and not anything tied directly to Apple. Likewise for other well-known forms of obfuscation like changing behavior based on the system date so that it appears fine until the review period is over—though the app could simply refuse to work when the date doesn't match the server, if there is a server component, and that wouldn't be particularly suspicious.
The main deterrent to trying any of that, of course, is that it will get not just the offending app but the entire developer account banned. Those accounts aren't free. Moreover, uploading an identical or even substantially similar app under another account would be recognized immediately, so you'd have to start over from scratch.
.png?view=open){kind=link}