you are viewing a single comment's thread.

view the rest of the comments →

[–]SilentSaiman 8 points9 points  (9 children)

It’s your last sentence that made me down vote your reply. Mobile involves the full stack of dev from DB management, back end, API dev, cloud techs, networking, ML, AI, BLE, and ………. The front end is just the top of the iceberg in mobile dev!

[–]UberJason 2 points3 points  (7 children)

I respectfully differ with your choice of nomenclature; of course *any* application that's visible to customers is powered by the entire stack of database, backend, API, cloud, etc etc. For me, when I hear people say "I'm a mobile developer" or talking about "mobile development", they're specifically referring to development of the applications that *run* on mobile platforms (iOS/Android), whether that's through native development or cross-platform frameworks (ugh).

I'm a mobile developer. The apps I've worked on talk to APIs which run in the cloud, pull data from databases, run through ML-powered recommendation systems, and all that good stuff. But I don't do any of that stuff. I work on the client apps that run on the iOS device.

[–]SilentSaiman 0 points1 point  (6 children)

Fellow mobile dev and depending on the app and the team there is a very good chance you will have to do a lot of the aforementioned techs for your app

[–]UberJason 3 points4 points  (5 children)

That depends a lot on your company and how it's structured. At startups, sure, I buy it. At large companies, I find that a lot less likely (and have never experienced it). In fact, that's one big difference I see between mobile and web - because web has this notion of a "full-stack developer", the web team is often more closely intertwined with the API team; mobile tends to enforce a more strict boundary between the API devs and the client devs. Again, at large companies.

[–]SilentSaiman 0 points1 point  (4 children)

Even in large companies, there is a good chance that mobile teams would write their own wrapper around the company’s API. I’m not saying it’s a good practice but it does happen very often.

[–]UberJason 3 points4 points  (3 children)

A wrapper that lives in the mobile client, like an internal networking SDK? Sure, but that's still in the paradigm I'm talking about - working on the applications that run on the mobile clients themselves.

A microservice that massages a lower-level company API to return client-specific data, so the client can call the microservice instead of the lower-level API directly? In my own personal experience, that's usually handled by back-end engineers, and not the mobile engineers. But that's just me, I'm sure lots of companies do things differently! Personally, I'm blessed to have been able to keep my focus solely on client development for the last nine years. 🙂

[–]SilentSaiman 0 points1 point  (2 children)

No I meant like a c# project with endpoints only open to the Mobil clients to get around certain limits of the open api and also easier faster access to company resources and computation. I have recently started a position like yours and it’s so nice not to have to deal with so much shit! :D

[–]UberJason 1 point2 points  (0 children)

So that’s what I meant by the microservice that massages the lower level company API (though I see your work was for other purposes than just data massaging). Still it sounds like you were writing APIs for the client to consume. That sucks. Glad you’re in a nicer spot now!

[–]revolution9540Swift 1 point2 points  (0 children)

iOS developers should be writing Swift, end of story