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

161–170 of 170 posts

Re: Apple acquires Buddybuild

#161

Post by izacus »

nasalgoat wrote: post #160
izacus wrote: post #125

Earlier quoted context omitted.

Putting off the Android version for two years is a great way to have your potential Android audience move on to your competitors and squander any marketing and networking effect. Noone remembers your app exists after a few months, why did you expect anyone to give a damn about your product after two whole years?!

Our app is in the top 10 grossing apps in the Apple App Store and we market it aggressively. Android users are just not as lucrative or numerous as Apple ones. During that two year delay we made the iOS version a quality product instead of having our attention divided by another platform that delivers less than 10% of the userbase. It was the right move.

What does "top grossing 10" on App Store have to do with anything? Do you think Android users regularly check out Apple App store to look for your software? :P

Your attitude is very common among iOS developers and it's the main reason why you only have 10% of userbase on Android - companies that actually understand their audience have no issues reaching wide users and profits on both platforms.

If you deliver a subpar submarketed product on App store you will fail. If you deliver a subpar submarketed product on Play Store you'll fail as well. It seems you did the second thing.

Re: Apple acquires Buddybuild

#162

Post by jjeaff »

sebleon wrote: post #158
jjeaff wrote: post #115

Earlier quoted context omitted.

In my opinion the new logic is build in React Native (unless your app fits in the 10% of use cases that won't work well with RN), then deploy to both at once. We have had excellent results.

My take is that RN is great for demo apps or simple UIs, but I would not choose it for a production app where performance matters (ie. using camera, audio, custom controls, platform-specific SDKs, multi-threading, etc). You're definitely going to do heavy lifting in native code, and a hybrid app quickly becomes a mess. Dealing with multiple environments and super slow build times in Xcode will seriously slow down dev…

That article is out of date. As of September 2017, FB has re-licensed React under the MIT open source license and dropped the patent stuff.

I don't think you contradicted anything I said. I would say special camera apps, multi-threading etc. are not needed that often.

As for slower build times, that is the beauty of RN. Building is not needed most of the time just an initial build and a rebuild every time some of the base configurations change or you are creating code outside of RN.

Re: Apple acquires Buddybuild

#163

Post by jjeaff »

rimliu wrote: post #127
jjeaff wrote: post #115

Earlier quoted context omitted.

In my opinion the new logic is build in React Native (unless your app fits in the 10% of use cases that won't work well with RN), then deploy to both at once. We have had excellent results.

I'd say RN won't work well in 99% cases.

I'd say you are probably using a lot more React Native apps than you realize right now.

Re: Apple acquires Buddybuild

#164

Post by sebleon »

jjeaff wrote: post #162
sebleon wrote: post #158

Earlier quoted context omitted.

My take is that RN is great for demo apps or simple UIs, but I would not choose it for a production app where performance matters (ie. using camera, audio, custom controls, platform-specific SDKs, multi-threading, etc). You're definitely going to do heavy lifting in native code, and a hybrid app quickly becomes a mess. Dealing with multiple environments and super slow build times in Xcode will seriously slow down dev…

That article is out of date. As of September 2017, FB has re-licensed React under the MIT open source license and dropped the patent stuff. I don't think you contradicted anything I said. I would say special camera apps, multi-threading etc. are not needed that often. As for slower build times, that is the beauty of RN. Building is not needed most of the time just an initial build and a rebuild every time some of the…

> fb dropped patent stuff

Ah, thanks for the update, glad they did that

> are not needed that often

Right - statistically most apps are probably throwaway code for hackathons or demos. However, I'd venture to say that >50% of serious apps will end up needing performance boosts from native code.

> Building is not needed most of the time

You need to rebuild every time you make a change in native code (obj-c or swift). Hot reloading is cool for JS changes, but bloat from RN becomes a nightmare when debugging obj-c or swift issues.

Re: Apple acquires Buddybuild

#165

Post by jjeaff »

sytse wrote: post #145
goblin89 wrote: post #122

Earlier quoted context omitted.

> Setting up a CI system yourself is maybe a bit harder than using a hosted solution. But if the provider decides to change their offering, you are in big trouble. I love how GitLab does it. It owns the parts watching your branches for commits and passing instructions to your machine, but the instructions themselves are a clean YAML file in the root of your repo, so if at any point you want to pack things and switch…

Yay, glad to hear that. And we're trying to make initial setup easier with Auto DevOps https://docs.gitlab.com/ee/topics/autodevops/ providing a default implicit gitlab-ci.yml file

Initial setup? I was amazed when I simply put my .yml file into the root of my repo and pushed to gitlab. It just worked and the job was running. What other initial setup are you referring to?

Re: Apple acquires Buddybuild

#166

Post by kristiansagi »

noarchy wrote: post #4
swozey wrote: post #2

Goodbye Android builds. edit: yup; On March 1, 2018 buddybuild will stop servicing apps on the Free Starter Plan. Also on March 1st, the buddybuild service will stop supporting Android apps for all plans. Any historical data related to those apps will be deleted from the service at that time.

This gives my current team two months to find a new solution. Buddybuild, aside from the odd issue from time to time, had been a great solution for us. Now we're suddenly wondering where to go next. Not to mention, we now face the question of whether to move our iOS apps off buddybuild as well.

We at nevercode.io wrote an overview of our platform for BuddyBuild users for easy migration. Have a look :) https://nevercode.io/welcome-home-android-developer/

Re: Apple acquires Buddybuild

#167

Post by kristiansagi »

CameronBanga wrote: post #7

If anyone has a good Android (or even iOS) replacement, share here? I know myself and likely many others will be looking to migrate this month.

We at nevercode.io wrote an overview of our platform for BuddyBuild users for easy migration. Have a look :) https://nevercode.io/welcome-home-android-developer/

Re: Apple acquires Buddybuild

#168

Post by kristiansagi »

exidy wrote: post #49
CameronBanga wrote: post #7

If anyone has a good Android (or even iOS) replacement, share here? I know myself and likely many others will be looking to migrate this month.

Nevercode (formerly GreenhouseCI) does iOS and Android. https://nevercode.io/

Overview of Nevercode platform for BuddyBuild users for easy migration: https://nevercode.io/welcome-home-android-developer/

Re: Apple acquires Buddybuild

#169

Post by kristiansagi »

toddgower wrote: post #75

I've been a Buddybuild user for the past couple months after watching the founder, Dennis, give a talk at a meetup. Great product with a super easy setup. Really bummed that I'll likely have to find a new solution after only two months (though I understand the founder's decision). Can anyone recommend a product with a similar ease of setup? Buddybuild was my first foray into mobile CI. Have not seen the need since ou…

We at nevercode.io wrote an overview of our platform for BuddyBuild users for easy migration. Have a look :) https://nevercode.io/welcome-home-android-developer/

Re: Apple acquires Buddybuild

#170

Post by nasalgoat »

izacus wrote: post #161
nasalgoat wrote: post #160

Earlier quoted context omitted.

Our app is in the top 10 grossing apps in the Apple App Store and we market it aggressively. Android users are just not as lucrative or numerous as Apple ones. During that two year delay we made the iOS version a quality product instead of having our attention divided by another platform that delivers less than 10% of the userbase. It was the right move.

What does "top grossing 10" on App Store have to do with anything? Do you think Android users regularly check out Apple App store to look for your software? :P Your attitude is very common among iOS developers and it's the main reason why you only have 10% of userbase on Android - companies that actually understand their audience have no issues reaching wide users and profits on both platforms. If you deliver a subpa…

Actually, the apps are virtually identical, except for platform UI differences to cater to each group. The Android audience is just not as valuable, dollar-wise, as iOS regardless of market share. Our subscription numbers prove it.
Post reply on HN