magsafe

Thank you, you bring up some excellent points.

One thing I didn't see mentioned in this article is Firebase. It feels like a hidden gem lurking within the overall GCP offering, and may be overlooked by devs who're not doing mobile-specific work. For me, Firebase was the gateway drug that got me into GCP. I successfully built and hosted the backends for a couple of iOS apps using Firebase. The best parts were cloud functions and built-in sync (including offline/occasionally connected sync scenarios). Firebase Cloud functions allowed me to convert an AWS Elastic Beanstalk project into a 100% serverless architecture, which basically runs itself with no ongoing maintenance or scaling required. It took a significant amount of work off my shoulders. Once I had a positive experience with Firebase, I started poking deeper into the Cloud Console. I realized I could use App Engine, Compute Engine and various other services, which all made perfect sense as "upgrades" to the core Firebase project. I've now migrated the backends of 2 existing, popular iOS apps from AWS to Firebase+GCP. Kudos to the Google team for making Firebase perfect for my needs, and the overall Cloud platform.

Does AWS offer something similar?

https://www.bottomlinehq.com Single founder/employee, 6-digit revenue, no outside funding.

Can this be used in React Native apps?

I'm a full-time iOS developer and want to share my perspective on this news. The developers who create those amazing apps on iOS are not going to fall for this. I'm one of those developers, who pays very close attention to detail to make pixel perfect apps that I'm proud to put my signature on. I will not accept my brand being introduced on Windows or any other platform using a glorified code generator. If I want to bring an app to Windows, I would learn the platform, go "all in" and make my app as perfect on Windows as it is on iOS. This would require me to dig into all the SDK docs, understand the platform capabilities, learn the native APIs, deal with the challenges of supporting different form factors, and a lot more. There is simply no shortcut to a great app, and a developer who is proud of his app would not release something that a machine generates. A great app is not one that has been thrown together using abstracted APIs and a code generator. A great app is one in which the developer has written and/or analyzed every line of code to maximize the aesthetics and performance on the platform it is running on. Windows' code conversion isn't going to encourage the really good apps to migrate, although it might entice some cheap knockoffs or poorly designed apps to ship an equally poorly designed experience on Windows. So bottomline, I don't expect apps like Instagram to suddenly appear on Windows because of this.

Also, developers don't avoid Windows because it lacked a code conversion tool. If all it involved was learning a new language or porting some code, developers would do it, just like they learned to go from Objective C to Swift, or all the evolution of Cocoa Touch through the years.

Developers avoid Windows for far more complex, intangible reasons that go way beyond a code converter. There are all kinds of perceptions about Windows and Windows users that simply will not change because of this tool. The iOS developers I know will shrug off this announcement, and continue shipping their apps on iOS. I admire Microsoft for overcoming the technical challenges of creating this tool, but sadly they have not overcome the perception and mindset challenges of a dieing platform.

Am I the only one that considers lunch to be a sacred, personal time that I don't want to spend on small talk with coworkers? I need my lunch break to recover from the day's stress and pace, so I can come back refreshed and ready to code for 4-5 more hours. As an introvert, I find the team lunches to be waay more stressful than actual work, and that eliminates any benefits of a nicely cooked meal. If I end up in a team lunch situation, I find it hard to be productive for the rest of the day (unless I take a separate mini-lunch break by myself later).

The situation was especially bad at one recent job where the lunch conversations always revolved around local sports, which I had no interest in, or this guy remodeling his house, which was only interesting the first 3 times he gave us an update. So I started bringing sandwiches to work, parking in the garage beneath the building, and eating lunch all alone in my car in the dark, listening to NPR or just enjoying the silence. It was the most refreshing hour of my workday and I felt 200% more productive after that break than I would after 30 minutes of small talk about sports.

I just want to point this out to people who think team lunches should be mandatory. Not everyone enjoys them equally, and it's not always just about the food.

I think this decision needs to be taken on a case by case basis, instead of a universal answer. You need to evaluate the lifecycle of the project. If this project is going to be around for only 1 year (like a game or marketing campaign that quickly ramps up and then dies down), you're better off getting it done in Objective C. The client will be happier given their familiarity with Objective C, and you'll have an easier time explaining it to their in-house team.

However, if this is longer term bet like an app that's going to be in use after 3-5 years, you should have a honest discussion with the client about considering Swift. While Objective C is more well understood and supported right now, that might not be the case in 3-5 years. Most Apple developers would rather be writing Swift code in that timeframe, and any ObjC code will be perceived as "legacy", difficult to debug, and abandoned code that no one likes to touch.

I've worked on many iOS projects like this, which contain pre-ARC code, which no one likes to go near. Bugs in that code tend to be ignored and entire features are left to rust because the source code is so dated that it's better to leave it alone than risk breaking anything by modifying it. If this project could end up in that state, it's better to be future-proof and start with Swift. However, if it's a short term app, choose the path of least resistance, which seems to be Objective C at the moment.

Since this discussion is about sales, I'd like to share a nifty little app for tracking sales that have already been made: http://www.bottomlinehq.com

Founder of Bottomline here. Happy to answer any questions about architecture, design or product. Love to hear any thoughts!

Apparently someone out there still uses Firefox.

Great attitude, and thanks for the clarification. Best of luck!

Core Data has been improved and stabilized by Apple for over a decade, is used internally by many first party apps in iOS, is well documented and fully integrated into Xcode, and heavily "marketed" by Apple at WWDC. Any perceived performance issues can be eliminated or reduced by using faults, indexes and improving queries through NSPredicates. Even one of the blog posts you quote above [3] states that if he was starting a new app today, he'd go with Core Data. So I'm just not seeing a need for yet another ORM solution. I'm not saying you shouldn't continue building it, but you guys need to do a better job explaining the differentiation against Core Data. One area could be sync, where Core Data still needs work, and is limited to iCloud's backend. Perhaps that could be your differentiator? But you're not talking about sync yet. So there's work to do in crafting your message. Fwiw, I'm a senior iOS developer who evaluates these things for a living.

What does this provide that CoreData doesn't? Whatever it is, it needs to be clearly explained on the landing page. Otherwise it's difficult to understand what problem this solves compared to CoreData.

Surprised that people still use "uber" as an adjective in 2014. It was cool in 2007.

I posted this question precisely to avoid having too many aliases. I'd like the equivalent of "dialing 0" from your hotel room phone, and getting redirected by the front desk based on your request.

It has a bit of a southern connotation that might be awkward for urban customers.

The design, typography, layout and mobile-friendliness are indeed brilliant. The simple white background and lack of navigation clutter really put the focus on the items being sold. Check out this photographer's store: https://squareup.com/market/mel-ashar-photography. Great job Square!

His LinkedIn profile has an alphabet soup of technologies and programming languages. Even if a recruiter did read it, like he requests, they would have no idea what this guy's real focus is. It even mentions Windows, as well as Xcode and iPhone development when he is clearly a server engineer.

Maybe he needs to revise or shorten his resume before lashing out at recruiters for not reading it. I'm not a recruiter, I'm a developer who makes $225k, has unlimited vacation and lives In San Francisco. As a developer, I feel that guys like him give us all a bad name and make us look arrogant, inflexible and hard to work with. Maybe this attitude is why he still doesn't make his ideal salary of 200k.

After this blog post I doubt he's going to get any other job, let alone one that meets his minbar.

iCloud offers one benefit over this, which is iCloud allows record-level syncing (for SQLite databases using CoreData).

Dropbox is file-level syncing. So if you have a database app managing many records in tables, Dropbox will sync the entire database when even a single record changes. iCloud would only sync the record(s) than changed.

Perhaps you should read Anonymous' press release before dismissing them. http://anonrelations.net/opisrael-95/

I agree with everything this article says, but the segment showing the Dave McClure pitch was the most "real" and fun part of the first episode. It was intense, exciting, and quiet realistic, if not a bit predictable (when Ben proudly states that he has 42 other businesses). In my opinion, the 5 minute segment filmed at Dave McClure's desk made up for sitting through an hour of b.s party scenes.

How is writing this blog post and submitting it to Hacker News not hacking the application process?

An old post from an ex-Microsoftie, which might explain some of this Windows RT mess:

http://windowsphonesecrets.com/2011/03/24/first-windows-phon...

I think the more appropriate advice is don't hard code strings anywhere in your source. Sometimes using such strings is unavoidable and the most practical thing to do (e.g bundle IDs in iOS apps). But if you have to use such strings, define them ONCE in one header file, plist file, or similar and use the reference everywhere else. I've used this successfully through several ownership changes of several apps across several platforms, and always found it to be a minimal, trivial problem - as long as the strings are cleanly #defined in one place.

No, it's anecdotal evidence.

I completely disagree. Most app/website referrals aren't verbal. Verbally communicated referrals are easily forgotten (e.g. "what was that photo sharing site Mike was telling me about at the party last night?") Most referrals are via an email that includes a URL, a blog post or tweet from someone you follow, or an email generated via the "Share" feature within the app itself. All of these eliminate the "search" problem, and reduce the time to launch significantly.

On the NASA site, look for the "Full Size" link, then right click on the image and set it as your desktop wallpaper. Fits perfectly.

My point was the app should never crash, for whatever reason. You need to handle failures gracefully.

Interesting idea, but can't get it to work. I created a test account and added 2 WordPress blogs to it: TechCrunch and the official Wordpress blog (http://wordpress.org/news/). Went through the steps, downloaded the sandbox app on my iPhone 4S and tried to preview them. App instantly crashes when loading both sites. Is it just that these blogs don't have the required JSON plugins (possible)? Or is it that they have too much content for Appifier to handle? Either way, an abrupt crash doesn't inspire confidence. Do you have any sample blogs we can try to test this with?