4 ms·

$499/month! That seems expensive - is it a big problem when Apple does a lot with App thinning? Big enough of a problem for $499/month?

by edf13 6y ago

sond813 6y ago
App thinning goes a long way if you're supporting multiple architectures, but if your app has a lot of code it can still get very big, very fast. There are many companies that have dedicated teams to trying to handle app size, but we've found that our tooling offers more without the maintenance and eng resource cost of building it internally. To support independent developers and small startups we offer a free Growth plan and have significant discounts available for higher build volumes. We think this is a fair alternative to having a development team or even one engineer focused on this problem.
- bluesign 6y ago
  App size is a problem, but as far as I know only challenge there is cellular download size. (thats why in your examples, dropbox and ebay doesn't care about install size) Main approach to this problem in industry is when you approach cellular limit, you optimize. I also agree that it is big engineering investment sometimes. But the problem is you are targeting low hanging fruit (stripping comments from localization, stripping symbols, optimizing images etc) or stuff that doesn't effect download size ( deduplicate files ) Those fixes are good for small startups, which you are giving away for free. The main engineering problem for big companies is binary size, optimizations like "reordering of the build optimization passes" etc. I would buy this as a tool, but as a service it is a hard sell for me.
  - sond813 6y ago
    Definitely! We want to reduce cellular download size as well. In the particular case of Dropbox, their download size is around 100mb right now. I just did a quick test by deleting the duplicate localizations in their Frameworks and zipping the .app which reduced compressed size by ~17mb (17%) so these optimizations would help significantly. This is one of the reasons I prefer to just measure install size. It's difficult to reason about all the combinations, but by reducing install size you're always on the right track to an overall smaller app. In my experience working on large apps like Airbnb we try to get ahead of the problem even before approaching the cellular limit, since a smaller size helps acquire and keep users, and we want to avoid architecture decisions that would become a problem down the road. It's not too rare for one of these low hanging fruit optimizations to be accidentally introduced in a large company, with testing on every PR you can catch them before they‘re introduced. Binary size is definitely what changes most often at these large companies and that's why our continuous monitoring lets developers know exactly the granular binary size affect of a PR. With a lot of code, things like exposing Swift functions to Obj-C which introduce new metadata can frequently be mistakenly added. For enterprise companies we also track the biggest modules in their binary, so eng managers can get a better understanding of where the size is coming from.
Grustaf 6y ago
Yeah that’s a lot. Engineers could spend several hours a month on app size and it would still be cheaper.
danpalmer 6y ago
This is not intended to be a justification for why I don't want to pay for this service, it's intended as honest feedback about the shock I had seeing the price, and why I think it might be, in the hope that it helps the team iterate their offering. This price feels wrong, and I think part of it is the pricing of the other similar sorts of service we use for our app, and that I suspect others use. Ultimately this service and the others are about improving reliability and quality in some sense, so while different markets I think they are comparable as teams can opt to focus on quality in different areas. - CI, we pay $100-200 for this, and it obviously consumes a lot of compute resources and needs to regularly. Price feels ~reasonable. - Crash reporting, we pay <$100 for this. It scales with user base, and while low cost per user this does feel like it has some scale to it. It's also essentially user-facing, so very high uptime requirements. - Code coverage, $5. It's basically a few database records behind an API with a special interface. Feels like it's worth very little, but fantastic price, worth it. Also coverage is similar metric to app size – a small change is probably ok, but long term trends are an issue, so in a way it provides a similar type of value. - And then we come to this. $500. The analysis is a complex bit of code I'm sure, and the company should be able to charge for that, but there isn't compute, (significant) storage, or high SLAs as a necessary part of the product. It feels "wrong" next to these other services. I think all of these feelings roughly boil down to intuition around the cost of goods sold (COGS). Logic that has already been written has a low COGS, and while that doesn't mean it should be free at all, it does make it hard to justify over being, say, a standalone piece of software that one buys once. Perhaps a way to circumvent this is to go hard on the constant evolution of the platform as Apple changes their technologies. Maybe this is all from the viewpoint of someone who would likely be on the free plan! And so maybe this is a non-issue, but we'd happily pay for this, it just feels like it's a $50/mo service not a $500/mo one.

$499/month! That seems expensive - is it a big problem when Apple does a lot with App thinning? Big enough of a problem for $499/month?

by edf13 6y ago

$499/month! That seems expensive - is it a big problem when Apple does a lot with App thinning? Big enough of a problem for $499/month?

sond813 6y ago

App thinning goes a long way if you're supporting multiple architectures, but if your app has a lot of code it can still get very big, very fast. There are many companies that have dedicated teams to trying to handle app size, but we've found that our tooling offers more without the maintenance and eng resource cost of building it internally. To support independent developers and small startups we offer a free Growth plan and have significant discounts available for higher build volumes. We think this is a fair alternative to having a development team or even one engineer focused on this problem.

bluesign 6y ago
App size is a problem, but as far as I know only challenge there is cellular download size. (thats why in your examples, dropbox and ebay doesn't care about install size) Main approach to this problem in industry is when you approach cellular limit, you optimize. I also agree that it is big engineering investment sometimes. But the problem is you are targeting low hanging fruit (stripping comments from localization, stripping symbols, optimizing images etc) or stuff that doesn't effect download size ( deduplicate files ) Those fixes are good for small startups, which you are giving away for free. The main engineering problem for big companies is binary size, optimizations like "reordering of the build optimization passes" etc. I would buy this as a tool, but as a service it is a hard sell for me.
- sond813 6y ago
  Definitely! We want to reduce cellular download size as well. In the particular case of Dropbox, their download size is around 100mb right now. I just did a quick test by deleting the duplicate localizations in their Frameworks and zipping the .app which reduced compressed size by ~17mb (17%) so these optimizations would help significantly. This is one of the reasons I prefer to just measure install size. It's difficult to reason about all the combinations, but by reducing install size you're always on the right track to an overall smaller app. In my experience working on large apps like Airbnb we try to get ahead of the problem even before approaching the cellular limit, since a smaller size helps acquire and keep users, and we want to avoid architecture decisions that would become a problem down the road. It's not too rare for one of these low hanging fruit optimizations to be accidentally introduced in a large company, with testing on every PR you can catch them before they‘re introduced. Binary size is definitely what changes most often at these large companies and that's why our continuous monitoring lets developers know exactly the granular binary size affect of a PR. With a lot of code, things like exposing Swift functions to Obj-C which introduce new metadata can frequently be mistakenly added. For enterprise companies we also track the biggest modules in their binary, so eng managers can get a better understanding of where the size is coming from.

Grustaf 6y ago

Yeah that’s a lot. Engineers could spend several hours a month on app size and it would still be cheaper.

danpalmer 6y ago

This is not intended to be a justification for why I don't want to pay for this service, it's intended as honest feedback about the shock I had seeing the price, and why I think it might be, in the hope that it helps the team iterate their offering. This price feels wrong, and I think part of it is the pricing of the other similar sorts of service we use for our app, and that I suspect others use. Ultimately this service and the others are about improving reliability and quality in some sense, so while different markets I think they are comparable as teams can opt to focus on quality in different areas. - CI, we pay $100-200 for this, and it obviously consumes a lot of compute resources and needs to regularly. Price feels ~reasonable. - Crash reporting, we pay <$100 for this. It scales with user base, and while low cost per user this does feel like it has some scale to it. It's also essentially user-facing, so very high uptime requirements. - Code coverage, $5. It's basically a few database records behind an API with a special interface. Feels like it's worth very little, but fantastic price, worth it. Also coverage is similar metric to app size – a small change is probably ok, but long term trends are an issue, so in a way it provides a similar type of value. - And then we come to this. $500. The analysis is a complex bit of code I'm sure, and the company should be able to charge for that, but there isn't compute, (significant) storage, or high SLAs as a necessary part of the product. It feels "wrong" next to these other services. I think all of these feelings roughly boil down to intuition around the cost of goods sold (COGS). Logic that has already been written has a low COGS, and while that doesn't mean it should be free at all, it does make it hard to justify over being, say, a standalone piece of software that one buys once. Perhaps a way to circumvent this is to go hard on the constant evolution of the platform as Apple changes their technologies. Maybe this is all from the viewpoint of someone who would likely be on the free plan! And so maybe this is a non-issue, but we'd happily pay for this, it just feels like it's a $50/mo service not a $500/mo one.