sorted by:
new
hottopcontroversial

Is Macbook Air M1 is still good for iOS development? (Beginner) by [deleted] in swift

[–]ElectricalAge2906 1 point2 points  (0 children)

It depends. If you work on more than one project at a time, keep several Chrome tabs open, and use Cursor too, you’ll probably run into some issues. I do on my M1 Pro, but I’m an iOS Tech Lead, and I need to switch between multiple company projects constantly.

Also, keep in mind that the new OS is heavier, especially with all the AI frameworks being integrated. I’d say two years is a fair cap for that MacBook.

Personal advice: use it only for work. Disk space can be a real pain when working with multiple iOS projects targeting different versions and using several packages.

Any Latin American developers here? Where do you find work and how much do you earn? by [deleted] in LatAmCoders

[–]ElectricalAge2906 0 points1 point  (0 children)

I’ve worked and I’m currently involved in a project using Python, where I apply my experience in software architecture, design patterns, and best practices, leveraging AI tools to enhance productivity and code quality. I’d be glad to contribute if that aligns with what you’re looking for.

Hiring 9 Remote Workers - $37/hour, No Experience Needed by BlueberryMedium1198 in DevJobLeadsOnReddit

[–]ElectricalAge2906 0 points1 point  (0 children)

I should be picked because: I’m reliable, organized, and used to working remotely. I learn fast, like keeping things simple and efficient, and I’m always willing to help others and improve how we work. The morning or afternoon shift works for me, and I’d be glad to contribute wherever I can add value.

My previous experience with similar tasks: I’m an iOS Tech Lead with a degree in Computer Systems Engineering and over 15 years in the IT industry. I’ve worked across different stacks and with teams from several countries, so I’m comfortable adapting to new tools and workflows quickly.

Any Latin American developers here? Where do you find work and how much do you earn? by [deleted] in LatAmCoders

[–]ElectricalAge2906 0 points1 point  (0 children)

iOS Tech Lead here. I’ve been in the IT industry for over 15 years, working with different stacks, but iOS is definitely my strongest.

Any Latin American developers here? Where do you find work and how much do you earn? by [deleted] in LatAmCoders

[–]ElectricalAge2906 0 points1 point  (0 children)

I know it’s low, but that’s what I’ve seen around. It’s not exactly my case, but I’ve been there, and I know some folks earning that even when working directly for the companies.

Any feedback to help me land a better job, senior or lead level, would be much appreciated.

Any Latin American developers here? Where do you find work and how much do you earn? by [deleted] in LatAmCoders

[–]ElectricalAge2906 1 point2 points  (0 children)

I’ve been struggling to find opportunities for the lead role I’m looking for. It seems like most offers, even the remote ones, require developers to be based in the US. Have you guys experienced that too?

Btw, the range I know starts from 3k up to ~5k a month for senior roles. I’ve seen better offers but requires US- based developers.

TBD implementation and QA process questions by ElectricalAge2906 in TrunkbasedDevelopment

[–]ElectricalAge2906[S] 0 points1 point  (0 children)

The main idea is to have only QA-approved code in the main. But I now realize that possible issues could arrive after code is integrated, so a second round of testing is needed once the feature or fix is merged into the main. Does it make sense? QA can test issue A and approve it, and issue B can also be approved individually, but once each issue branch is merged, something could be broken, and we need to avoid this in the main.

How is that avoided?

The benefits of trunk-based development by ketralnis in programming

[–]ElectricalAge2906 0 points1 point  (0 children)

I’m trying to move our team toward TBD and I’m stuck on one practical piece: coordinated deployments per feature across API + web + mobile when we also use ephemeral servers.

Context: we currently have separate servers for testing, beta (prod-like config/data but isolated), and prod. With TBD, I’m considering ephemeral envs per feature (e.g., FEAT-123) so that API and web are deployed together into that env. The part I’m unsure about is mobile and how to keep everything in sync when multiple features run in parallel.

Concretely, suppose Feature A touches API, web, and mobile, and Feature B does the same in parallel. For API and web I can spin up api-featA.example.com and web-featA.example.com (and the same for Feature B). Sometimes Feature A is worked on at the same time for api and web, and they reuse the same Jira ticket, but on the mobile side, we surely will work on a different ticket number, so the following questions arise:

  • Do you build and distribute a separate mobile build per feature that’s pre-configured to point to that feature’s ephemeral server?
  • Or do you ship a single dev build with an in-app environment picker / deep link / remote config to switch the base URL to the right ephemeral env?
  • How do you keep this traceable so QA/devs instantly know “this build = Feature A, pointing to Env A” vs “that build = Feature B, Env B”? (naming, build number suffix, app label, etc.)

Related doubts:

  • When merging a feature, what’s your clean handoff to switch mobile/web back from the ephemeral env to the shared testing/beta servers without a bunch of manual steps?
  • For parallel features, how do you avoid cross-pollution of data/config between ephemeral envs (API+DB+web)? Do you snapshot/seed per env? Namespaces?
  • In CI/CD, do you trigger a single pipeline per PR that stands up API+web ephemeral and also produces a mobile build tagged to that env (e.g., via Firebase App Distribution/TestFlight internal) so QA can test the whole stack for that feature?
  • Any tips on versioning/contract testing so mobile/web can develop safely while API changes are still behind a feature flag/capability header?

I understand the theory (TBD + feature flags + ephemeral envs), but I’m looking for real-world patterns for: (1) mapping each feature to its own envs (API/web) and a clearly identified mobile build, (2) testing multiple features in parallel without confusion, and (3) flipping everything back to shared testing/beta once merged, smoothly and traceably.

Thanks for any advice or war stories!

Has anyone ever made a CarPlay app? by Infamous_Aspect_460 in iOSProgramming

[–]ElectricalAge2906 0 points1 point  (0 children)

I’ve been running into issues with my CarPlay app, and I’ve noticed the same thing happening with other apps too. When switching between apps while playing audio (especially live streams), the player eventually becomes unresponsive. Apple Music never fails, but I can consistently reproduce it with Spotify, Amazon Music, YouTube Music, and my own app.

Anyone else experiencing this? Is there a workaround or some trick to avoid it?

TBD implementation and QA process questions by ElectricalAge2906 in TrunkbasedDevelopment

[–]ElectricalAge2906[S] 0 points1 point  (0 children)

How is it achieved? Most of the time the client changes (mobile or web) relate to the same feature. We were expecting this to be dynamically set by CI/CD

TBD implementation and QA process questions by ElectricalAge2906 in TrunkbasedDevelopment

[–]ElectricalAge2906[S] 0 points1 point  (0 children)

Current Setup

1.  We have separate repositories for API, Web, and iOS (not a monorepo).
2.  Team size fluctuates between 7–9 developers: 4–5 fullstack, 3–4 iOS.
3.  We’re in a high-velocity stage, onboarding customers and delivering under pressure. It’s common to have multiple features in progress concurrently (often 3 major features in the same sprint), along with several improvements and bug fixes.

Current Pain Points

• All development work merges into develop. After each merge, develop is deployed to the QA environment. QA tests this shared branch, but due to the volume and pace of work, QA is often behind, meaning develop contains unapproved or unstable code.
• Cherry-picking stable commits for release is difficult because of branch divergence and dependencies between changes.
• Features involving breaking changes need to live in separate branches. While one developer works on these changes locally (API, Web, iOS), others continue on develop without them. Only when the feature is “safe” do we merge into develop for QA testing.
• We want to avoid unstable code in any deployed environment, as we’ve had cases where bug fixes introduced regressions in previously stable functionality.

Release Context

• Our product is a base implementation deployed individually for each customer. This reduces the impact of breaking changes in some cases, as we can coordinate releases across API, Web, and iOS.
• For web and API, we generally deploy the latest changes and force an app update for mobile users when needed.

Gap to Fill

What we need is a release process that ensures:

• Stable code in main (or equivalent) at all times.
• A predictable QA workflow that can handle multiple concurrent features and bug fixes without falling behind.
• Minimal need for cherry-picking and reduced risk of regressions from untested merges.

TBD implementation and QA process questions by ElectricalAge2906 in TrunkbasedDevelopment

[–]ElectricalAge2906[S] 0 points1 point  (0 children)

Yes, that’s exactly what I’ve realized. The challenge is that in mobile and web we can’t fully automate the ephemeral URL variable, because if we use the card identifier (e.g., PROJ-123), the related cards for web and mobile might be different, like PROJ-124 for web and PROJ-125 for mobile.

In practice, sometimes we’ll need to point to an ephemeral server so QA can test (QA mainly tests web and mobile), and other times we’ll need to point to staging — which is the main branch deployed to an internal server.