In this podcast episode, Alex Logan, Lead Mobile Engineer, chats about how, after all that hard work of creating a product, you can win developers over with your product.
You can listen to the full podcast interview on Spotify and Apple or enjoy the highlights of our convo in this article.
My accidental journey into iOS engineering
I'm an iOS Engineer now, but I actually stumbled into being an iOS engineer, and my journey to computer science was genuinely an accident.
When I was going to university, I wanted to do business stuff. Before that, for my A-levels, I was doing design. So, I’ve been all over the place through different paths of education.
When I went down to Cardiff University to look at business and economics courses (because I presumed that's what I was going to do), I literally got on the wrong bus. I was supposed to be going to the business school, and I ended up at the computer science school.
It was a really long journey, and I was thinking, Well, this is taking ages. So, when I got there, I thought, Well, I may as well stay here now.
I walked in and I had a moment where I thought, Wow, this is so cool. There were old Apple computers all over the place, and the course description sounded so fun.
On the way back, I panically rewrote my personal statement to be all about computers. And luckily, I ended up getting into Newcastle University doing computer science.
But then, when I was at university, there was a certain time when I wondered if I’d made a mistake because it was all Java and text on a screen. It was all just sat in a terminal and I just didn't get engaged in it.
So, I started to look at apps, and because I had a MacBook, I figured I might as well try Apple stuff.
I tried Apple's tutorial for iOS, but I hated it because it was Objective-C, so I abandoned it completely. In the same cafe where I was sitting doing tutorials and getting annoyed by Objective-C, I ended up seeing a flyer for an event they were doing for local start-ups, which was a super lucky coincidence.
I met a guy who ran a local agency, and I jokingly asked him after this event, “Do you hire freshers?”
And he said, “If they're good enough.”
My response was, “Oh, okay. Maybe not yet.” So, I left things there. But then, during my second year, I decided to do an internship, and luckily, that same guy was hiring. I thought, Well, I'm clearly going to try and work there, and luckily got in.
When I was there, I joined as a web dev. I was doing PHP, JavaScript, and so on. But there was only one iOS dev there. They were an app agency. So, what ended up happening was that I snuck my way in. I didn't ask anyone, I just started doing iOS tasks. I thought, Well, if I just do them, I'm not going to get told off for doing more work.
I kept doing things, and I completely messed up my first push to the App Store. I didn't know what I was doing. I thought, Sure, I can push a new build to the App Store, which pointed to a development server and no one could sign in. That was an interesting morning.
But I accidentally got into computer science and snuck into iOS, and that's just been what I've done ever since.
I also picked up Android because I was always really curious about it. I always had this idea in my head that the end game for my career was going to be head of mobile, similar to what I’m doing now where I need to know about both platforms. Picking up Android gave me a better understanding of the ecosystem.
But that's how I got here. I’ve been in iOS ever since and worked at various companies. I’ve always worked on my own apps on the side; Coffee Book, which was App of the Day, and Snippet, which is still featured on Mac OS App Store.
And then, of course, I've worked on a bunch of freelance stuff where I was very lucky. That's how I got the top trending spot in both stores at once. I designed and built an app that ended up being at the top of both, which was fantastic.
Now, I find myself doing a little bit of everything: design, Android, iOS, and more importantly, developer marketing.
Developing products with marketing in mind
All the way through the development stage of your product, keep it in your head that someone else is going to be using this. That means that the code should be pretty self-documented and there should be comments, and so on. It should make sense for people. If someone else picks this up, they should understand it.
You need to think about flexibility as well. If I as a developer was integrating my product, what would I be looking for? And you have to constantly reflect on that.
With every single thing you build, you have to keep thinking, Okay, what's this like as the consumer? This feature might be really cool and do all this magic stuff, but that might not be nice for a developer to actually use.
And then, of course, with everything you do, you need your documentation site to be up to scratch. A couple of months back, we completely redid our documentation site. Instead of focusing on explaining each individual part of a code one by one, we decided that we should explain how to use it.
Mariya Delano
When you're coming to us, you want to use this for a certain reason. That might be for push notifications. When a developer is adding push, they don't come to our doc site and start searching around for the exact classes. They're coming to see a guide on how to set up notifications.
So, we’ve switched up our approach to building things, making sure they're documented well, but then also adding these guides on the website. It’s been a good thing and certainly a bit different. I personally enjoy writing a lot.
We’ve also added video guides. We've had four or five of those now, which I think are quite useful for people to see both sides of things.
You're marketing to developers, but at the same time, you need to make sure that product people understand what's going on as well because it's not just devs that are going to be pushing your SDKs and tools internally. So, it’s been interesting to balance that in some of the videos too, making sure that people understand it.
Lots of documentation is a sure way of doing it, and always remember that you aren’t the consumer. You're the one building it, but the consumer is the thing that matters.
Striking the right balance when marketing to both developers and product people
Our product essentially removes the need for the developer in a lot of ways. You can set content live remotely, you can do it based on events being triggered, and so on.
For all these things, we normally go to a dev, and they'll say, “Okay, it’ll take me a day or two.” And then you go to the App Store, and it's quite slow. Our idea is that you can replace the dev.
So, we have a situation where we have to market to the product person and say, “You can replace the developer, and you don't need to wait days for the App Store.” But we also have to prove it to the developer and say, “You'll have to do less. You put this product in one time, and then you can get back to doing the fun stuff.”
We always try and echo that point in all of our marketing, that ultimately, this benefits both people. The devs can build the stuff they actually want to build, the fun stuff like widgets or whatever toys they want to play with. And then the product people can experiment and build what they want without having to go to the dev.
It does benefit both of them, and you have to constantly remember that in marketing. It’d be really easy to send out a bunch of cheeky tweets saying, ‘You don't need a developer anymore,’ which will be great for product people. But then if you send that to a dev, they're not going to be happy about that.
It’s just constantly making sure that everything is balanced, and making sure that we never at any point accidentally insult one side of a conversation by marketing to another.
There are a lot of competing solutions and a lot of people who try to do what we do. But a big thing we talk about a lot is design. We say, “We’ve designed good-looking stuff for you so you can skip that bit.”
And again, I also have to make sure that I don't tell a designer that I don't need them anymore. I have to say to them, “Hey, this is actually really good for you because, like a dev, you can get back to the fun stuff.”
So, it's very interesting when you have a product that benefits everyone, but in very different ways. How do you balance that?
Building convenient products for developers
One question that I certainly ask whenever I see a new framework or tool is, “Why would I not just build this myself?”
To give you some examples, frameworks are coming out all the time that say, “Hey, we'll handle payments for you,” or, “We'll handle crash reporting,” or something.
It’s really easy to look at them and say, “Well, I can build that myself in a couple of days, and I don't have to pay anyone. I just have to use my own time.”
So, you have to make sure that when you're showing your product to people, especially developers, you offer functionality and quality that can't be replicated super quickly. You have to keep remembering that at all times.
Teresa Garanhel
If I'm offering something that a dev can build in a couple of days, then why wouldn't they just go off and do that? I have to be so convenient that the developer almost forgets about the fact that they can go build things. They’d just rather use me and throw in my two-liner, rather than going off and building their own thing. It's a pretty hard thing to manage.
For example, if someone comes to your product and they only want a tiny part of it. A good example is that we offer stories. If you just wanted stories, it’d be really easy to say, “Well, I'm just going to go and make my own stories.”
You have to make sure that, even if someone comes in for just one feature, you end up convincing them that the other stuff is worth it too, and get them to buy more into the whole system.
Not necessarily to migrate everything they do over, but at least make it so that they're using more than just one feature, so they’re more likely to stay when they’re here, or they’re more likely to come in to begin with because they see a whole bunch of things that appeal to them.
If you look at people like RevenueCat, their product wraps around payment systems, and they have to show why you should use them and not just build your own StoreKit wrapper, especially as Apple makes it better every year.
And really interestingly, I asked this question in a private developer Slack channel and loads of people came out in support of the RevenueCat implementation instead of building it themselves.
It proved to me how much that matters because they were all picking out things that I wouldn't have thought of necessarily. For example, ‘It's really convenient because I get server notifications,’ or, ‘I get real-time reporting.’ All these tiny little things add up to mean that doing it yourself doesn't make sense. You can't build all those things.
They're a spectacular example of how to do that when you have something that can be rebuilt, adding more features on top that really encourage the people. People love that product, and it's the same thing we're going forward with too.
Finding the right audience when marketing your app
Marketing is always hard because, in computer science, there's so often a correct answer. I might think, Okay, I need to make a list in my app. I'll use a list and I'll do this functionality, and I'll add swipe to delete, and it's really straightforward.
But with marketing, there's not necessarily a straight answer. You have to try a whole bunch of different things and go from there.
When developing an SDK in particular, there's a lot of trying to market individual features on their own and marketing as targeted as you can on the platforms where these people are.
For example, when we were marketing Unflow to designers and put it on Figma, it did really well because it was on the right platform for the right people, and they saw it and clicked through to Unflow.
For developers, there are a lot of developers on Twitter and Mastodon now too, so it’s making sure that the right platform sees the right content.
It's hard to tailor content for people. As I said before, you want to make sure you appeal to the right people without demeaning another group, so you have to make sure you're careful of that, especially on Twitter.
It's not like Twitter is segmented into developers, designers, and product folks. You need to make sure what people see appeals to everyone, whether that's through adverts or just tweets, and so on.
For me, marketing is just about finding where the people are that you want to speak to, and doing your best to make something that appeals to them. It's very hard to get that right. There's no guarantee if you have the cheekiest tweet or the best demo video on Reddit that people will like it, but I think you just have to keep trying.
It's about a lot of persistence and hoping that eventually, you'll get through to the right people. Just keep trying. Don't give up. You might tweet 100 things with zero likes. But just keep going. Keep posting to the right people and eventually, it’ll work if you have a good product. But you just have to keep going and keep trying on various platforms.
There’s a really good piece of advice I saw from an indie developer on Twitter. Someone asked, ‘If you had two days to market your app, what would you do?’
And this developer, a person called Jordi Bruin, who’s a really successful indie dev, said that he’d just make 50 Reddit posts. It sounded extreme, but when you think about it, it actually made sense. So what he talked about was the idea of going and finding really niche groups that happen to fit.
It’d be really easy for me to say, “Let's market to developers,” because developers are a huge, huge group. You’ve got front-end guys, back-end guys. There are people in all sorts of areas. It's about finding the niche. These might be really tiny groups, but if you're really hyper-specific when you're posting in these groups, you might do really well.
For example, with the design stuff, I posted it in Figma design, and it did really well. Whereas when I posted it in the UX design one, it didn't do particularly well. I'm sure if there was an onboarding subreddit somewhere that I could find, I could post it there.
It’s about a lot of frequency and just finding the right place. But again, volume was so important. 50 Reddit posts is pretty extreme, but I think that's probably the right way to go. Just post as much as you can in the right places, and just find the ones that stick.
Teresa Garanhel
Securing developer buy-in: Product adoption strategies and challenges
If a developer is a person pushing your product to their company, then you're in a really good spot. And I think that whenever a developer advocates for a product, it's probably going to stick and they'll probably keep using it.
When developers see the product for the first time, whether that's a product person bringing it to them or they found it themselves and they're taking it to their own company, you have to make sure that they're bought in at that point.
The challenge with that is that you have to get buy-in for the whole system. It can't just be like, “I like this one tiny feature.” They have to like the whole thing, which is hard. I find that the marketing that does the best is really niche and it’s showing them a certain thing.
For example, ‘Hey, we can make your onboarding better.’ But I think the best way to convert people is for them to buy into the whole system.
You have to find the hook that brings people in, but then make sure once they are in that you show them everything else as well. For example, that might be a really hyper-targeted login page. We have one on our site just for onboarding, where the top is all about onboarding, but then the rest of the page shows you everything else we do.
So, make sure that people are aware of everything that's available to them, not just, ‘Hey, here's this one thing you want.’
That's hard to do. When you think about that, that might mean 10-20 different, specific landing pages for people. But the tools exist out there to make that a bit easier. You can use a template page where you change the header. I think that's a pretty useful way to do it.
You can do that for marketing too. On Twitter, for example, you might have the same advert running 10 different times with a slightly different URL. You have to make sure that you’re doing that and you're selling people on your whole product, and that you prove your value to them straight away.
It's not easy, but I think if you do follow strategies like having dedicated web pages or making sure wherever they find you, they find a lot of information that's enticing, you're in a good spot.
I think that experimentation with this stuff is huge. I'd love to be able to sit and say, ”I've worked it out. That strategy I’ve just described will work.” It also might not. You might find that you do way better with just one super page that describes every single feature you have. It's not tailored and it's just an incredible landing page.
A really good example would be the Linear landing page. That’s gone viral a few times recently for how pretty it is. Maybe that's the right way to go. The only way you'll find out is by experimenting, and I think you definitely should.
I tweet about developing for Apple platforms all the time. I’ve done it for years and years, and there's been blog posts and so on.
There's content which I think is really good and it’ll be the most liked thing on my website, but when I put it on socials, it doesn't do very well at all. And then one day, I’ll randomly post a picture of my computer in a coffee shop and it’ll get triple the likes of anything I've ever posted. And I’ll think, Oh, okay, I didn't expect that.
But it’s just about consistently trying stuff. I wasn't thinking, I'm going to tweet this and it's going to go viral. I just happened to have my Mac in the background and people wondered, What's this app? And it worked out really nicely. But it was a complete coincidence and I'd never think of doing that. So, just keep trying.
Pulkit Agrawal
Why is it so hard to market to developers?
Expectations are rightly, really high. If I'm going to put a framework into my app, especially one where I have to pay for it, I expect it to be fantastic. I expect it to tick all the boxes. I expect zero crashes.
I expect all these wonderful things, and I almost need to get that impression from the first time I see the product. So whether that's from influencers tweeting about it or I see it on GitHub, I need to be convinced from the start that this looks good. I want to see frequent releases, I want to see cool release notes. The standard is so high, and there are a lot of frameworks that meet that standard.
When you're starting from zero, that can be quite hard. I've never discouraged anyone from starting. If you have an idea, but don't necessarily have the time to build out some crazy GitHub repo and all this stuff, then just ship it anyway and see.
A lot of hard work has to go into getting people to like what they see. Sometimes, what you have is just so spectacular that people don't care. But often, you do have to put that extra bit of work in and convince people that the quality is as they expect.
You often get a bit attached to your apps. I know people shouldn't, but a lot of people do, rightly. Their code base becomes a thing and they look after it and maintain it. They get a little bit attached to it. And as a result, if they’re bringing something new into that, it has to fit in, and it has to be up to their standards, so you have to meet that.
The main challenge with that is that you don't know what that bar is. I think that bar is different for every single developer. For a brand new dev who's writing their first iOS app, they might see a new framework and think, Oh, cool, and throw it in straight away, no questions asked. They’re thinking, “This is great. I don't have to do that anymore.” And they do it.
But someone a bit more seasoned, like your principal iOS engineer or Android engineer at some big company, might be way higher in terms of standards and start going through all the code they can see, checking all the documentation, and really analyzing things more.
You have to appeal to both of those people. Make sure that the person whose standard is just, “Ooh, it's pretty,” is met, and then the person who really wants the super technical, really clean stuff is also appealed to.
It's quite hard to meet that, but I think it's very possible if you just keep considering the consumer when you're building things.
For example, when you're building your README, make sure it's nice, make sure it's friendly, make sure it's usable, and make sure you're responsive to issues. Just put the effort in and make sure that you're welcoming to those different standards.
As a developer, you're marketed to so much. Of course, everyone is marketed to a lot these days, but developers get so much hyper-targeted advertising everywhere. For example, every time I open Reddit or Twitter, I get adverts for frameworks and tools, and I'm just really aware of it.
I think the most successful marketing a lot of time for companies is influencer-based marketing. So, they'll have a DevRel person, and the DevRel person will tweet something cool like, ‘Hey, look what I was working on today.’ And you'll be thinking, That's awesome. Oh, that's where you work, isn't it? You represent that company.
I think it's really cool to see this with people's posts. But there's almost a thing in the back of your mind where you realize, Hang on. But it's an advert, isn't it? It doesn't necessarily say ‘ad’ on it, but realistically, it's an ad. And I do think it affects things.
I think you can see that in action. If you look at companies who have quite a lot of DevRel folk and also have their own company Twitter account, if you compare the reception of content on both accounts, across the board, the person's account will do better than the company's, even with the exact same content.
This is because people are less likely to see what the person posts as an advert and more of a, ‘That's so cool! Look what you've built!’ And then they’ll like it and engage with it.
People being savvy to marketing is totally an issue, and probably why individual-based marketing does so well, because they like the person that they're reading.
It’s a bit like when you look at reviews for a movie. You find reviewers that you like and engage with, and then you stick with them. If you're following someone already and you already liked them and they happen to post about something, you're more likely to be happy about that than if you see a company pop up on your timeline saying, ‘Hey, please subscribe to our new thing.’
Teresa Garanhel
Beta testing: Balancing consumer needs with developer adaptations
We’ve done some betas in the past. But the approach that we took for it, and it actually worked quite nicely, was the idea that a feature is led by the consumer.
For example, someone was using a framework, and something that happens at Android is if you have two frameworks that both depend on the same thing and one of them has a higher version number, it’ll pick the higher version number, which can mean that one of the frameworks is working with a framework it doesn't understand very well. This can lead to crashes and bugs, and so on.
So, we had someone who said, “We really need this version number bumping.”
What we could say was, “Hey, we're going to do that, but that would mean we drop support for these devices.”
We released it as a beta and warned everyone by saying, “Hey, this is the preview of the next few releases, just on its own. If you want to switch to that now, go ahead. But it's a beta, just to warn you.”
This was great because the guy switched to it straight away and said, “Thank you, it's great. It works fine.” And then for the next update, we could switch to that for everyone. And we do the same right now for iOS.
For example, in iOS, generally, what happens is that Apple releases a new Xcode in September/October. It’s the big one for the year. And then you have until about April to switch over, when Apple says, “Okay, if you want to push to the App Store, you have to use the new Xcode.”
However, a lot of people, and bigger companies in particular, don't switch Xcodes for a very long time. A lot of people will take until the very last second to switch Xcodes, which means I can't use the fancy new Swift stuff. That means maintaining a version of the SDK that works on the older version of Xcode, and then almost having this preview version available for people.
So, I say to them, “Hey, this is what it's going to be like. Switch to it now, or we recommend you switch to this as soon as possible. But if not, feel free to use the old one. So it’s essentially having that second track of, “Here's the future, really cool one, and then here's the older one. You can use it if you want, but you don't have to upgrade,” which I think is quite important.
Also, something else you have to remember is that every release has to be up to a really, really good standard. You have to consider that some companies might not update their app very often.
So, even though I might be saying, “Hey, this is a beta release,” someone might ship that, and that might be on the App Store. And if there's an issue with it, then that could be a crash that's affecting hundreds or thousands of users.
You have to bear in mind that all the time, even with these different release tracks, you set the expectation of, “If this is a beta, please don't put it in your App Store app.” And if it's a live release, then you have to make sure it’s completely perfect.
Aleksandar Micev
Harnessing multiple social channels to attract developers to your app
To attract developers to your app, it's about using social, but it's also about using multiple channels for social. Not just using a company account, but also using personal accounts.
We've made sure that when we tweet something on personal accounts we link back to Unflow, but it’s about making use of all the different channels and trying to build that social proof with people.
There was something I got told a while back when I interviewed to work at an Apple store. They said that they have this expectation that someone might come into the store to look at a MacBook five times before they decide to buy it. You just have to make sure that each time you're showing them more and more of what they’d like.,
And then eventually, when they do come in and they've made their mind up that today's the day they’re going to buy it, you've done your job. You've convinced them. And then you're ready to give them something that they’ll love.
I think the same thing applies to developer tools. They might see your tweets or your adverts 5-10 times before they bother to click on one and go, “Go on, let's see what this is like.” I think it's about making sure that you do get in front of people in multiple different ways.
For example, if all they saw was the same advert for the SDK five times, they're not going to be bothered. But by showing them different use cases and different ideas, you're building up that trust so that they might eventually click on it and say, “Okay, this looks pretty cool. I like this.”
Just use all the channels possible. Maybe try social channels that you wouldn't necessarily consider. YouTube Shorts is a big one. We've started posting things on YouTube. TikTok is also skyrocketing in popularity, and a lot of brands are doing quite well over there.
So, stick to social as best you can, use every channel possible, and just try. I'd never made a YouTube video explaining code before. I've written blog posts, but I've never done a video. But I’ve done a few now, and developers really liked them, the ones that I actually showed them to anyway. So it’s worth having a go and trying some different things. Take a look at what other people are doing too if you ever get stuck.
It’d be really easy to just get someone in to look at your social strategy and do it all for you. But when you're doing it yourself as a developer, I think the strategy is just to keep trying. Eventually, you might need to admit that you need some help if it's not going well. But as a developer marketing to developers, you know who you're marketing to because you are one, so you'll eventually strike the right chord.
Check out other podcast episodes on Spotify and Apple and, for more insights into the developer marketing landscape (as well as the marketers and developers who are part of it), download your free copy of our State of Developer Marketing Report.
