mattschmulen

Yup, really they had the right idea in that it was native components that were hoisted by JavaScript binding... it really lost steam because it became easier to just build native Swift (and later kotlin android). It was a solid play at the problem in it’s time. Note: I worked at Appcelerator in the “gogo” years and it was great, and they/we almost made it happen in a real way.

How else do you identify your mbp going through TSA. Call me laptop roulette paranoid.

I have had some nice results with swift. It’s still predominately Apple tech (macOS,iOS) but the packages manager is nice and it’s has nice “script” feel for a compiled language.

Great article, I love seeing server and client side worlds colliding. It reminds me of the early days of lib-uv/nodeJS. In addition to the swift NIO specific endeavors I’m excited about the integration work with Swift package manager (spm) and xCode. I think there is real impact on sharing server side and client side models/serializers similar to Android and JavaScript isometric models. It’s not effective for every project, but for many iOS first endeavors itnhas real value in the design & define stages of app creation. Very cool

In my humble experience the impact of this issue is multiplied on mobile; given the mobile context the user expectation is in amplified and the need for clear communication made more relevant. A simple “spinning wheel of death” is often not enough. However, I’m not bought in on the term ”benevolent deception”. Where I’m from we differentiate this by differentiating being honest with being earnest. “The importance of being earnest” (forgive the pun) is that the earnest person has your objectives/priority in mind regarding the outcome for the recipient. An honest persons is an indifferent to the outcome or result. The earnest person is looking out for you.

If I had a dollar for every time an XO, Sales VP, or board investor (I’m looking at you Todd Rulon-Miller) said we were expecting an IPO filing in two years (bless thier optimistic little hearts) and sold for executive bonuses and a common stock price for the parts then I would have 3$. Best exit I ever had was an XO who’s singular prediction statement was “I think we have a chance at building and contributing to this technology and I think that might be valuable to this software enterprise segment, do you want to go find out?”. Buyer beware, contributor beware; it’s just how the game goes. Look for the humble introspective and you increase your odds, there is no guarantee, you only control your investment. That’s a tough break for those that were over exposed you have to cap your liability to your comfort level. bummer for those that caught the bill.

When choosing a language, framework or “platform” there are only three things that matter:

(1) Time to market: how fast can you implement a “ship-able” feature, app

(2) Resource cost/availability: can you find delivery resources easily and cost effectively. Sometimes this resource is you, metric appropriately.

(3) Scalability: as you grow and features change, how do the other two things change. Do they change for the better or the worse.

The weighting of these depends on longitivtiy expectations. If your short sighted for immediate reward weigh (1) and (2) higher if your confidence is high on the outcome of what your doing then weigh (2) and (3) higher.

For this discussion Swift wins on almost all fronts. The exception might be legacy maintenance , and even then it might be a knife fight of when and how.

While legacy iOS developers are justifying objective-c over swift. Swift is “eating the world” of iOS and macOS app ( and some server side ) development, avoid it at your own peril. The Xcode issues are undeniable but it does not change the situation. swift lang is superior and it is the overwhelming choice for new apps and new developers.

Completely true for the last two years, however if the last two months are any indicator things are looking up on this front. The swift 4 update was relatively painless compared to 2 and 3.

How is this measured? I'm a big fan of Vapor, just curious

All this and the developers that were driving new line of biz products were coming from the front end ( web and mobile ), of course all front ends need backends and when these these folks went looking they naturally leaned toward JavaScript the same language they were using on the front end and Async model

It's amazing how much nautical language and references contribute to colloquial phrases. It may be just the company I keep but I find it consistently comes up in French.

I would add to that oil and gas project managers. When I moved to SF from Dallas I was astounded how little Product Managers assessed resource costs + risk to value. I get that it's a different world with different objectives but there were clear moments in the SV where some good old fashion blue collar project management would have made a significant impact.

I agree with a lot of this. My one comment is that not all side projects are about a "full startup business". I shipped my 2 mo. side project this summer. Donors Choose Project Finder https://appsto.re/us/JVmbab.i . It was 100% pro bono , and to keep my skills sharp. So far over $20,000 in supported donations. Keep an eye open for the next set of features :)

Great write up

Fantastic! I'll move over my server side Swift WIP prototypes ASAP . https://github.com/mschmulen/yachtsServer

I don't understand why (forgive me for the generalization) blue collar work ethic and blue collar loyalty are so often dismissed in the tech field. Some of the best advice I ever received was 'execute in the seat your in'. Sure there are higher order strategies to work out but grow into it and growth is around growing into the company, not just growing into your specific vertical profession. Kudos on your directness.

I think test after is a reasonable approach. I am constantly dealing with new code bases and in the interview process I am often asked about my philosophy about testing. My response is thatbtrsting occurs on two fronts from the top down ( functional UI tests) and from the bottom up (unit tests). When it comes to unit testing my approach is to focus on the hotspots. If something gives you trouble, or if you find a bug/ issue then wrap it in a unit test. That way you don't have to worry about it. Bugs tell you where the weak spots in your code base are. When they speak to you, listen and take some action. Otherwise, I feel like chasing blanket coverage is not worth the effort in most products.

Similar to Texa-duetche https://en.m.wikipedia.org/wiki/Texas_German ... Contributed words like skunk to English.

Hey I have some time behind the iOS Dev "wheel" (about 12 iOS apps shipped, some better than others :/ ) , I'm between jobs/contracts and just hanging out so if you want someone to bounce questions off of feel free, or even better we can schedule 45 min and I'll give you the walk through of the fora and fauna of iOS SDK's ( it's not that hard after a bit of coaching ) . my email is in my profile . Good luck !

I like this approach, and I use it a lot in my Objective-C to swift conversions. For new code (or legacy apps without testing infrastructure) I tend to approach testing first from the top down with Functional tests (uix button pressing) and defer the majority of unit testing until something is broke. If I find a bug in a subsystem than I almost always but a unit test around it. I hate the idea of fixing something twice.

The mocking component is a critical component in this. My networking constructors dependency inject the network config ( PRODUCTION, STAGE, MOCK ). Over the past few months I have been trying different strategies on the mocking. I have done it with local embedded JSON files for the mock network endpoint and also localhost swift server, serving the JSON mocking file overt the network. I like testing across the wire instead of responding with mock data from inside the app because ( as was pointed out in the article ) the functional user experience is often in response to the network response error and response duration.

In the past I have rolled my own swift mocking server, but I will give Embassy a try over the next week. Its always nice to have this type of thing in your developer "tool belt" for future projects.

Thanks for the contribution envoy.

I'm doing about 10 hours a week on it, I figured I would 'soft launch' it rough instead and polish it up as I get closer to the start of school year .

Hey that's pretty cool. I just did a similar thing, I started about 3 weeks ago on Donors Choose app https://appsto.re/us/JVmbab.i it's not for profit or anything , just figured I would do a small side project in the evening while I hang out with my kids over summer break

Fun little project(app)! Great Job! Nice work!

I'm going to fork and make a few small changes :)

very clean and clear presentation a couple questions:

- I noticed you had a pretty simple sales pipe flow ( New, Lead, Op and Close ) which is nice but do you plan on extending it or allowing customization? - Do you think you will embed a MEDDIC methodology into the flow ? - Mobile app / API ?

consolidation and fragmentation tension is the weapon of choice in mobile

As apps grow, and features increase there is always a pressure towards a "mega app” of many features and an opportunity for the "micro app” of focused features. The old adage of “Desktop apps are novels and Mobile apps are proverbs” may not hold as mobile matures, there is nuance.

Mobile applications are especially sensitive to this pressure of feature growth since the users are often interacting in short “mobile minute” spurts of need at a specific time and location ( of course not in all cases, youtube iPad engagement is much longer). The juxtaposition of large apps that support the desired feature and a small app that just does the one desired feature is where larger app stakeholders are trying to hold user base by providing the best of both words by splitting up apps and creating app ecosystems “constellations”.

Some things that are not discussed in this article that discounts the current state of mobile apps is the new integration/federation capabilities provided by mobile platforms such as deep-linking, custom actions and widgets.

Another interesting situation is how a “north star” or “keystone” app may fit into this by providing the highly valued "single sign on” authentication feature for an app ecosystem. I despise login screens and passwords fields in mobile and its Im happy to install a second app so long as you federate authentication.

Maybe in the end one app makes a product but two make a platform ( or maybe just skip the ‘app’ all together and make an API )

It seems a worthwhile experiment. I Just pre ordered ... now how do I get this thing to Panama City, Panama? Love the low carbon footprint angle.

ok you have may attention ...

- Will you provide a native SDK (Android, iOS) ?

- Lets talk about international banking ... Specifically any current plans to be licensed in Panama?

FML I turn 40 in May ... And your right it's time to man up and honor alone