iOS Reddit App Apollo's Developer Surprised by WWDC Callout(old.reddit.com)
old.reddit.com
iOS Reddit App Apollo's Developer Surprised by WWDC Callout
https://old.reddit.com/r/apple/comments/141kfmi/wwdc_2023_event_megathread/
28 comments
> probably because there's no good way to offer a service with a mobile app without having to design and engineer for the least-common-denominator.
Isn't the "good way", just to not treat "mobile" as a monolith, and instead have a separate team, with separate competencies, develop a separate app for each platform, such that each app can take advantage of all the strengths of each platform?
Back in the early console-game times, if you had made an arcade game, you'd have one company, who knew Nintendo programming really well, do your Nintendo port; and another company, who knew DOS PC programming really well, do your DOS PC port; and so forth.
Why did we stop doing that? Companies had enough money to do it back then. And the same companies are 100x richer now. They can totally afford a development team per platform, targeting that platform natively.
Isn't the "good way", just to not treat "mobile" as a monolith, and instead have a separate team, with separate competencies, develop a separate app for each platform, such that each app can take advantage of all the strengths of each platform?
Back in the early console-game times, if you had made an arcade game, you'd have one company, who knew Nintendo programming really well, do your Nintendo port; and another company, who knew DOS PC programming really well, do your DOS PC port; and so forth.
Why did we stop doing that? Companies had enough money to do it back then. And the same companies are 100x richer now. They can totally afford a development team per platform, targeting that platform natively.
> Why did we stop doing that?
cost and hard to measure returns (i.e. the cost of not doing so doesn't clearly show up anywhere)
building two apps can easily be twice the frontend dev (and worse maintenance) cost and a higher backend dev cost too (but not twice).
Theoretically with the right abstraction and flexibility wrt. to how UI components get data you can have less the twice the cost. But getting that right is hard and needs somone who knows what they are doing forcing that decision and having the time/will to setup the skeletons rightly and educate how to keep things "the right way" to not fall out this sync pattern etc.
Practically this tends to not be viable in bigger orgs (they don't want to take the risk of the expert getting it wrong) and bigger teams (they tend to have very mixed skill levels and things will get bad at some point leading to increasing dev cost approaching 2x if not some costly refactoring is done in time).
That a lot of teaching in the App dev scene seems to be more like "here how you do it the Apple way it's the only right way", "here how you do it the Android way it's the only right way" instead of "here are the concepts, this is how they apply with Android, this is how they apply with Apple etc." probably doesn't help either. I know it's a stereo type but I have just meet way to many app devs which do not understand the underlying concepts of both the framework they use and the language and don't realize it. (I also have meet the opposite, so maybe saying there are a lot of bad devs out there is more appropriate.).
EDIT: I nearly forgot: That you have to use not just different frameworks but different languages per platform to do it "fully right" succs bad, like really bad.
cost and hard to measure returns (i.e. the cost of not doing so doesn't clearly show up anywhere)
building two apps can easily be twice the frontend dev (and worse maintenance) cost and a higher backend dev cost too (but not twice).
Theoretically with the right abstraction and flexibility wrt. to how UI components get data you can have less the twice the cost. But getting that right is hard and needs somone who knows what they are doing forcing that decision and having the time/will to setup the skeletons rightly and educate how to keep things "the right way" to not fall out this sync pattern etc.
Practically this tends to not be viable in bigger orgs (they don't want to take the risk of the expert getting it wrong) and bigger teams (they tend to have very mixed skill levels and things will get bad at some point leading to increasing dev cost approaching 2x if not some costly refactoring is done in time).
That a lot of teaching in the App dev scene seems to be more like "here how you do it the Apple way it's the only right way", "here how you do it the Android way it's the only right way" instead of "here are the concepts, this is how they apply with Android, this is how they apply with Apple etc." probably doesn't help either. I know it's a stereo type but I have just meet way to many app devs which do not understand the underlying concepts of both the framework they use and the language and don't realize it. (I also have meet the opposite, so maybe saying there are a lot of bad devs out there is more appropriate.).
EDIT: I nearly forgot: That you have to use not just different frameworks but different languages per platform to do it "fully right" succs bad, like really bad.
You seem to be describing the thing that most companies still are doing (at least a little bit), where the same team does apps for each platform. And sure, that's dumb and hard — polyglot programmers are hard to hire, it's hard to context switch, etc.
But what I'm describing is different: in the old "porting" approach, rather than having "a mobile team" that is expected to know both iOS and Android, you would instead have an iOS team full of people hired specifically for their iOS expertise, that just do your iOS app, and who are not expected to know anything about Android; and vice-versa for an Android team. Your iOS team would be as distinct from your Android team as current mobile teams are from web-app teams (in companies whose native apps aren't just wrapped web-apps.)
I know this isn't too relevant for SMBs who can't afford to hire O(N) entire teams just to launch an app on O(N) platforms.
But the "let's share one codebase to every platform" efforts are almost always driven by corporations so large and so profitable that they can definitely afford O(N) teams of per-platform deep experts. Why is "the Facebook mobile app" a single shared codebase for every mobile platform? Why is "the Google Maps mobile app"? Slack and/or Discord (who used to be SMBs, but at this point could totally afford this)? Etc. These are all apps that would highly benefit from tight integration with each targeted platform.
It almost seems like the smaller companies are the ones who more often have the "taste" to do the right thing here; while bigcorps — that can actually afford to do the right thing — are constitutionally incompatible with this idea somehow.
But what I'm describing is different: in the old "porting" approach, rather than having "a mobile team" that is expected to know both iOS and Android, you would instead have an iOS team full of people hired specifically for their iOS expertise, that just do your iOS app, and who are not expected to know anything about Android; and vice-versa for an Android team. Your iOS team would be as distinct from your Android team as current mobile teams are from web-app teams (in companies whose native apps aren't just wrapped web-apps.)
I know this isn't too relevant for SMBs who can't afford to hire O(N) entire teams just to launch an app on O(N) platforms.
But the "let's share one codebase to every platform" efforts are almost always driven by corporations so large and so profitable that they can definitely afford O(N) teams of per-platform deep experts. Why is "the Facebook mobile app" a single shared codebase for every mobile platform? Why is "the Google Maps mobile app"? Slack and/or Discord (who used to be SMBs, but at this point could totally afford this)? Etc. These are all apps that would highly benefit from tight integration with each targeted platform.
It almost seems like the smaller companies are the ones who more often have the "taste" to do the right thing here; while bigcorps — that can actually afford to do the right thing — are constitutionally incompatible with this idea somehow.
In my experience it's mostly the not very small but also not very large companies _which have a small set of very excellent programmers_ which do so, with some tech lead spearheading it and having the skill (but not time) to pull it of just by themself.
But in larger companies this kind of team structure is rare, fleeting and if it exists most times focused on other more core business areas.
I mean in a start up you might find people with skills they could get highly payed for working for a fraction of their salary due to various freedoms and work atmosphere aspects, so you might have an excellent skilled person you can put (or which puts themself) on working on such UI tasks.
But in a large company you have this rarely, most highly skilled people there are also highly payed and in turn to expensive to put on such tasks which on paper don't yield that high value (not on a "they can't afford it basisi" but on a "it makes financially no sense" basis).
Similar even if that isn't a problem such people tend to be much more constrained by other influences.
Then there is the problem that software development isn't that easy to scale (I think most more experienced people know the "onboard a person to gain speed but losing speed" kind of situation). So often approaches to development become more stream lined, with more overhead, and in turn more expensive (but scaling to more devs). At which points considerations for cutting costs come in and in turn the "only one app" decisions is on the table. A good technical example is if you compare (a bit older) react + full reflux with the dart blocks pattern at the core they are the same but the react one is scaling better with many devs while also but in turn also has more overhead by splitting more things apart spreading you logic across all kinds of (standardized) places.
Through probably most important companies do not thing in terms of "can we afford it" but in terms of "does that yield enough profits for it to be worth it" (assuming they can afford it).
But in larger companies this kind of team structure is rare, fleeting and if it exists most times focused on other more core business areas.
I mean in a start up you might find people with skills they could get highly payed for working for a fraction of their salary due to various freedoms and work atmosphere aspects, so you might have an excellent skilled person you can put (or which puts themself) on working on such UI tasks.
But in a large company you have this rarely, most highly skilled people there are also highly payed and in turn to expensive to put on such tasks which on paper don't yield that high value (not on a "they can't afford it basisi" but on a "it makes financially no sense" basis).
Similar even if that isn't a problem such people tend to be much more constrained by other influences.
Then there is the problem that software development isn't that easy to scale (I think most more experienced people know the "onboard a person to gain speed but losing speed" kind of situation). So often approaches to development become more stream lined, with more overhead, and in turn more expensive (but scaling to more devs). At which points considerations for cutting costs come in and in turn the "only one app" decisions is on the table. A good technical example is if you compare (a bit older) react + full reflux with the dart blocks pattern at the core they are the same but the react one is scaling better with many devs while also but in turn also has more overhead by splitting more things apart spreading you logic across all kinds of (standardized) places.
Through probably most important companies do not thing in terms of "can we afford it" but in terms of "does that yield enough profits for it to be worth it" (assuming they can afford it).
Because more frameworks and abstraction make it feasible to not do that.
I absolutely agree with you and wish companies cared enough about the quality of their experiences, but it’s not economically required so most companies naturally won’t do it.
I absolutely agree with you and wish companies cared enough about the quality of their experiences, but it’s not economically required so most companies naturally won’t do it.
The underlying problem is that it's difficult to make high-quality cross-platform apps. A symptom of this problem is that companies create low-quality cross-platform apps instead of high-quality platform-tailored apps, because it's cheaper. I don't think we should treat the symptom by spending more money on platform-tailored apps. We should treat the disease by making platforms more interoperable.
The underlying "problem", then, is capitalism — and what you're highlighting as the "problem" is rather the benefit of it.
Companies seek to differentiate themselves in the market by offering features that their competitors don't have; and companies that offer platforms seek to win mind-share for developing on their platform, by building out hardware features that their competitors don't have. That's where technological innovation comes from.
Companies seek to differentiate themselves in the market by offering features that their competitors don't have; and companies that offer platforms seek to win mind-share for developing on their platform, by building out hardware features that their competitors don't have. That's where technological innovation comes from.
There's also a product reason – now you have to explain two different UIs to people, support them, etc.
>Very nice if they did this as a supportive gesture
The whole reddit API kerfuffle happened like 4 days ago. I think the presentations were recorded well before then- FWIW Kojima was in Cupertino 2 weeks ago
The whole reddit API kerfuffle happened like 4 days ago. I think the presentations were recorded well before then- FWIW Kojima was in Cupertino 2 weeks ago
Idk. about the Apple eco system but this always had been strange for me.
But on Android there are very clear easy to understand and explained rules about how to do material design, but somehow basically no app (including most ones from google) get it right.
My guess for the Android ecosystem is (at least theoretical) unnecessary programmatic complexity when implementing the "how", but then I'm not an App developer so idk.
But on Android there are very clear easy to understand and explained rules about how to do material design, but somehow basically no app (including most ones from google) get it right.
My guess for the Android ecosystem is (at least theoretical) unnecessary programmatic complexity when implementing the "how", but then I'm not an App developer so idk.
If they did it as a supportive gesture, the irony would not be lost on me. Apple notoriously despises 3rd party clients. They don't even have a web client for iMessage.
Permalink to the comment for those interested: https://old.reddit.com/r/apple/comments/141kfmi/wwdc_2023_ev...
Can someone explain for those of us who don't know? The comment links to this image right now https://imgur.com/6liBpal and I see Disney+ and then some streaming media phone app.
Apollo App is a popular UI for Reddit because their App and website are famously terrible (and Apollo is slick and awesome).
Reddit told Apollo dev they would soon be charged $20 million per year.
https://news.ycombinator.com/item?id=36142285
So various Reddit communities will go dark for 48 hours to boycott / protest
https://news.ycombinator.com/item?id=36196343
Reddit told Apollo dev they would soon be charged $20 million per year.
https://news.ycombinator.com/item?id=36142285
So various Reddit communities will go dark for 48 hours to boycott / protest
https://news.ycombinator.com/item?id=36196343
This was a picture taken by Apollo's developer, Christian Selig. It's just him showing he was there in person. While he got an invite to watch the event at Apple's campus, he was surprised by the shout out.
For more context, with Reddit's API licensing fees, his app will go defunct should they continue forward.
For more context, with Reddit's API licensing fees, his app will go defunct should they continue forward.
Oh I see, the photo is unrelated to the shoutout. The shoutout itself is described by this user https://news.ycombinator.com/item?id=36205917
Thank you.
Thank you.
Hi @dang, you may want to replace this submission's link to this
What was the callout exactly? Was it a presentation where they showed the logo or interface - or did they directly call it out by name?
Either way its awesome
Either way its awesome
When showcasing macOS widgets (46:18) Craig mentioned he could now add his favorite iOS widgets to the macOS desktop, including "Apollo for Reddit"...
Here's a direct link: https://www.youtube.com/live/GYkq9Rgoj8E?feature=share&t=279...
I think it was Craig that specifically pointed it out in his iPad Widgets or something.
Apollo has received subtle call-outs before. I've seen the app icon in the montages before. Not sure how many times.
Unfortunately, Apple has a huge problem where the only developers that really "get" making great iOS apps are independent people or small teams. Every other major app is some kind of weird amalgamation of half-busted UX concepts from various platforms, probably because there's no good way to offer a service with a mobile app without having to design and engineer for the least-common-denominator.
I'll also add that Apple's own iOS apps are often much worse than the third-party competitors in the space in terms of design and functionality, and update on a glacial yearly cycle, but have deeper platform integration than most developers can muster.