Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple acquires Buddybuild

buddybuild.com

Post reply on HN
Print view View original

81–90 of 170 posts

Re: Apple acquires Buddybuild

#81

Post by on_and_off »

scarface74 wrote: post #79
on_and_off wrote: post #28

Earlier quoted context omitted.

Wow, from these 2 examples, Apple looks like an awful acquirer :o

You have three types of mega corps. 1. Vertically integrated 2. Horizontally integrated 3. Conglomeration (not integrated) And there is a "strategy tax" in whatever method you choose. Except for FileMaker and Beats, Apple is mostly a vertically integrated company. They have no real desire to be everything to everyone like Google. If they didn't play to their strengths and tried to service Android users, it still woul…

That's really not the point.

I have no problem with Apple deciding to abandon BB on Android. It would indeed make very little sense for them to continue to support this platform.

What I am complaining about is the shut off date, it is very close.

Re: Apple acquires Buddybuild

#82

Post by Pharaoh2 »

Pharaoh2 wrote: post #40
sidlls wrote: post #15

Earlier quoted context omitted.

If I were to seriously attempt to commercialize the toy apps I build for my kids/family I'd go iOS first easily. People with Apple devices are far likelier to pay, and Android development is, in my view, an inferior experience (although Kotlin makes it marginally less so these days).

This may have been historically true, but our internal data shows us that starting early 2017, people in tier 1 countries were equally likely to pay and have comparable LTV on both platforms. And if you also going to launch in EU/Australia/Canada, you will have a nearly 50-50 split of ios and android users on a platform neutral app. So the classical logic of implementing on iOS first doesn't really apply anymore. Now…

Edit: s/comparable LTV/comparable ROI(~= LTV-CPI)

You will have equal ROI, with the LTV being slightly lower on android but so too will the acquisition cost... overall profit being the same.

Re: Apple acquires Buddybuild

#83

Post by st3fan »

jagger27 wrote: post #78
pm90 wrote: post #31

Earlier quoted context omitted.

Apple is notoriously bureaucratic. So its not surprising that innovation is stifled. I really hate this duality b/w innovation and stability... perhaps if more startups were focused on longer term survivability, it would be better for society overall?

I wonder if Apple's satellite operations (like the Siri team in Ottawa, Canada, for example) might have some autonomy and self direction simply due to distance from the mothership. As for a shift in startup culture, what is more tempting than 5 to 10 years of hard work into billion dollar exits? Local governments could start offering tax incentives that build over time—or more aggressively, have steep disincentives o…

Siri team in Ottawa? I find that hard to believe. Why would such an important team not be on the main campus?

Re: Apple acquires Buddybuild

#84

Post by bradrydzewski »

st3fan wrote: post #41
cshenton wrote: post #30

Earlier quoted context omitted.

I’ve been using drone, which is open source. It’s the only CI tool I’ve found writing pipelines in to not be painful. Need a test DB? The syntax is just docker compose so you already know how to get yourself one.

People who cared about BuddyBuild probably don't care much about Docker or "generic" CI services. There are plenty of those. The thing about BuddyBuild was that it was "iOS Specific". You could point it at a repo and you would have your project building, signed and ready to install, in minutes . This was pretty unheard of. And still is. Trying to get iOS projects to build and sign on generic CI services like Travis,…

What would it take to enable iOS builds in an open source project like drone? It is true that drone is primarily focused on container runtimes (linux amd64/armhf/aarch64 and windows) but perhaps we could have a separate yaml and agent that executes a pipeline on the host machine, perhaps using sandbox-exec for isolation.

Re: Apple acquires Buddybuild

#85

Post by nasalgoat »

mullingitover wrote: post #6

And just like that, by dropping Android support, Buddybuild goes from viable solution to total non-starter. Does any serious mobile app development these days really go all-in on one platform?

We put off an Android version of our app for nearly two years to concentrate development on the iOS version, and the numbers we get from our Android version - less than 10% of the market and 1% of the subscriptions - prove that was the right thing to do. We'd drop Android completely as the wasteland it is if not for the PR optics of having it.

Re: Apple acquires Buddybuild

#86

Post by skywhopper »

pm90 wrote: post #31
st3fan wrote: post #29

I'm happy for the founders, this is probably a good and profitable exit for them. But as a customer I am really sad and disappointed. Apple has a very bad reputation when it comes to taking over products like this. TestFlight is the prime example. TestFlight basically disappeared for a year until coming back as a more limited and slower Apple branded service. And by slow I mostly mean, it takes 6 months for bugs to b…

Apple is notoriously bureaucratic. So its not surprising that innovation is stifled. I really hate this duality b/w innovation and stability... perhaps if more startups were focused on longer term survivability, it would be better for society overall?

Innovation and stability are tautologically in opposition to each other, alas.

Re: Apple acquires Buddybuild

#87

Post by sidlls »

Pharaoh2 wrote: post #40
sidlls wrote: post #15

Earlier quoted context omitted.

If I were to seriously attempt to commercialize the toy apps I build for my kids/family I'd go iOS first easily. People with Apple devices are far likelier to pay, and Android development is, in my view, an inferior experience (although Kotlin makes it marginally less so these days).

This may have been historically true, but our internal data shows us that starting early 2017, people in tier 1 countries were equally likely to pay and have comparable LTV on both platforms. And if you also going to launch in EU/Australia/Canada, you will have a nearly 50-50 split of ios and android users on a platform neutral app. So the classical logic of implementing on iOS first doesn't really apply anymore. Now…

That's interesting. I am admittedly using my recollection of data I saw a year or so back. Has the fraction of iOS users who pay gone down or the fraction of Android payers gone up?

Re: Apple acquires Buddybuild

#88

Post by jayd16 »

nasalgoat wrote: post #85
mullingitover wrote: post #6

And just like that, by dropping Android support, Buddybuild goes from viable solution to total non-starter. Does any serious mobile app development these days really go all-in on one platform?

We put off an Android version of our app for nearly two years to concentrate development on the iOS version, and the numbers we get from our Android version - less than 10% of the market and 1% of the subscriptions - prove that was the right thing to do. We'd drop Android completely as the wasteland it is if not for the PR optics of having it.

That doesn't really prove anything. You may or may not have first mover advantage if you sit for two years.

Re: Apple acquires Buddybuild

#89

Post by rtpg »

skywhopper wrote: post #86
pm90 wrote: post #31

Earlier quoted context omitted.

Apple is notoriously bureaucratic. So its not surprising that innovation is stifled. I really hate this duality b/w innovation and stability... perhaps if more startups were focused on longer term survivability, it would be better for society overall?

Innovation and stability are tautologically in opposition to each other, alas.

I've found that this doesn't have to be the case.

Continuous deployment is a good example where this doesn't hold. You roll out things more quickly... and you experience less issues!

When issues happen, the cause is easier to isolate. After all, you only had one day's worth of changes (and not one year's worth). The previous state is more knowable. Testing is more concentrated.

Apple's new OS releases are the opposite of this. They release 30 different major changes at once, they all collide, and we end up just assuming that .0 releases will be broken.

In an alternate universe, Apple just releases updates to parts of software when it's ready. They don't pin Safari to the OS (because there's not much of a technical reason to). They could pinpoint _when_ "Month 13" started showing up everywhere beyond "when everyone downloaded that 7 gig update".

It takes some effort and tooling, but if you're expecting to make changes, a lot of times making the changes piecemeal will mean that post-release stability will increase in many cases.

Post reply on HN