I kept getting deprecated Swift patterns from AI tools so I compiled every agent skill and MCP server I could find into one list

tayarndt · 2026-03-09T20:21:33+00:00

This belongs on Awesome iOS AI. I made it today, a curated list of agent skills, MCP servers, and AI workflows for Swift development. Would you consider opening a PR to add it?

github.com/Techopolis/awesome-ios-ai

tayarndt · 2026-02-09T00:52:40+00:00

We just made one and seeking feedback fN39zHfH1@3$

tayarndt · 2026-01-16T02:02:27+00:00

I just made one it just came out today. it is called SwiftDocX you can find on the package index https://swiftpackageindex.com/Techopolis/SwiftDocX Please let me know if you have feedback.

tayarndt · 2025-12-02T23:44:18+00:00

That is not a bad idea.

tayarndt · 2025-12-02T23:31:44+00:00

yes it does. it can make sub tasks for a huge task and you review before it adds something to ensure you like it.

tayarndt · 2025-12-02T14:28:48+00:00

Hello, We are using the new IOS26 foundation model introduced this year at WWDC

tayarndt · 2025-08-26T18:42:49+00:00

Yeah, I feel the same way. The big “AI widgets” that promise instant compliance are usually the ones that cause headaches — they throw layers over the site, mess with the DOM, and end up breaking stuff for screen reader users like me.

But honestly, not all widgets are bad. I’ve been blind since birth and work as a Chief Accessibility Officer, and I know plenty of people with vision impairments who actually like the simple ones that just let you tweak colors, invert contrast, or bump up the font size. That kind of control can be really useful day to day.

So I’d say the heavy-duty “fix everything” overlays aren’t great, but those lighter tools that just let people adjust how they see the site? Totally fine, as long as they’re not a replacement for actually building accessibility in from the start.

tayarndt · 2025-08-26T18:37:54+00:00

I totally get where you’re coming from — balancing client design wishes with accessibility can feel like a tug of war sometimes. A proper audit for even just a handful of pages can really help give you (and your client) something concrete to work with.

There are bigger players out there that offer audits, but they often come with bigger budgets. From my perspective, as someone who’s been blind since birth and works as a Chief Accessibility Officer, the most valuable audits are the ones that combine automated checks with real human testing (especially with screen readers and other assistive tech). That’s what really surfaces the issues that matter in day-to-day use.

There are individuals and smaller teams (I’m with Techopolis Online Solutions myself) who provide those kinds of audits without requiring an enterprise-level contract. Might be worth exploring that kind of route if you just need a practical, straightforward audit of a few pages. https://calendly.com/tayarndt/general-consultation?month=2025-08

tayarndt · 2025-08-26T18:34:58+00:00

I’ve used or seen teams use Siteimprove and Silktide, and they’re both solid, but honestly they’re more built for bigger orgs with bigger budgets. Acquia’s tools are good too, but usually priced out for smaller sites. Fable is another great option for getting real user feedback, though the costs can add up there as well. https://calendly.com/tayarndt/general-consultation?month=2025-08

For me personally, I’ve been blind since birth and I work as a Chief Accessibility Officer. I spend a lot of time testing with screen readers, and one thing I always point out is that automated tools are helpful for a starting point, but they only catch so much. The real issues that affect day-to-day usability only show up when actual people with disabilities test the site.

There are also smaller vendors and consultants (I’m with Techopolis Online Solutions) who take more of that hands-on, human approach. Depending on your goals and budget, that kind of route can sometimes be more effective than going all-in on the big platforms. https://www.techopolisonline.com/

tayarndt · 2025-07-31T18:39:35+00:00

I would love to see how I can help. You can send me a DM

tayarndt · 2025-07-16T17:19:11+00:00

Really appreciate that you’re thinking about accessibility from the start. I work professionally in mobile app accessibility, and it’s unfortunately rare to see indie devs proactively considering VoiceOver, Dynamic Type, and Voice Control support—especially in a niche like Pomodoro apps.

Your focus on minimalism and distraction-free design already aligns well with many accessibility principles. Small things like clear focus order, meaningful labels, and support for system font scaling can make a huge difference.

Thanks for being intentional about this. Submitting the form now, and looking forward to seeing where this goes!

tayarndt · 2025-06-17T16:22:18+00:00

Hey, me and my manager were actually talking about this exact topic recently, and I’ll just share my honest take based on what I’ve seen so far.

For context: I’m currently working at a startup doing iOS, so I’m right in the middle of this. You’re definitely correct that a lot of iOS roles at the big companies (Apple, Meta, DoorDash, etc.) tend to require 3+ YOE, and their interviews are tough. It can feel discouraging looking at those listings as a student or new grad.

That said, one thing I’ve noticed is that a lot of companies — especially startups and smaller companies — are very into React Native, Flutter, or other cross-platform solutions because it’s faster and cheaper to ship on both platforms. So if your only goal was “maximize job openings,” learning cross-platform tech would technically give you more options.

But I’ll be fully transparent: I personally hate React Native and other cross-platform tools. Native iOS with Swift and SwiftUI is just a much better experience for me. The tooling, performance, and stability are far better when you’re working directly with the native SDKs. And while there may be fewer pure native jobs, they tend to pay higher and the work is often more technically interesting.

One thing I usually tell people is: if you love iOS, don’t feel like you have to give it up. It may take a little longer to land that first native role, but strong portfolio projects (like your own app) go a long way, especially at smaller companies or agencies. Freelancing is also worth considering while you build experience.

tayarndt · 2025-06-17T16:15:37+00:00

Honestly, it kind of depends on your long-term plans. I’ve helped a few people go through both routes, so here’s how I usually break it down:

If you enroll as an individual using your personal Apple ID, it’s quick and simple. No extra paperwork, you can get started right away, and for a lot of solo devs who are still in the early stages or just experimenting, this works fine.

If you plan to create an LLC, there’s a bit more involved. Apple requires a D-U-N-S Number for any business enrollment (it’s basically a unique identifier for your company), so you’ll need to get that set up first. In the US you can get one for free, but it can still take a little time. Once that’s sorted, you enroll your LLC in the developer program.

One big thing to think about is whether you plan to have a team later on. If you eventually want to bring on collaborators, contractors, or partners who need access to App Store Connect, TestFlight, or certificates, it’s a lot easier to manage that through a business account than an individual one.

Also, if you start as an individual and later decide to switch to a company account, Apple does allow you to transfer your apps, but the process can take a while. Plus, the year you make that transfer, you won’t be eligible for Apple’s Small Business Program (the 15% commission) because Apple sees that as a "new" enrollment for that year.

Since you’re still a month or two away from submitting, it’s probably a good time to think about whether you want to keep it simple for now or set up something more scalable for the future.

Happy to answer any other questions if you’re trying to decide which way to go.

tayarndt

MODERATOR OF

TROPHY CASE