7 ms·

> Urban Airship (now just Airship) Ironically, Urban Airship (now just Airship) itself is great example of something that people use even though they don't nee

> Urban Airship (now just Airship) Ironically, Urban Airship (now just Airship) itself is great example of something that people use even though they don't need it - due to hype. You have a mobile app and it needs to send notifications, but you don't have any in-house expertise on mobile notifications. Management says, "ok, let's outsource this to somebody who has some expertise!" They look around and find Urban Airship - the leader in mobile app notification handling! So you "integrate" with Urban Airship, per management dictates (the same reason you used Hadoop, Cassandra and Kafka). They give you this big complicated presentation but you discover that, in order to use their "service" you have to: 1) instrument your application to send their API a notification every time something happens in your application. 2) set up a workflow in their system that tells them when to tell you that something happened that a notification needs to be sent for 3) instrument your application to read a dataset from them telling you when to send a mobile notification 4) actually send the mobile notification You realize that they're charging your company a ton of money to do... absolutely nothing. You're still doing everything, responsible for everything, and they're nothing but completely empty overhead. They could have been replaced by a Postgres instance running on a single underpowered EC2 node (and it would be more reliable). But management sees "leader in mobile app notifications" the same as they saw "leader in distributed computing loads" and insisted that you use this thing that exists because it exists.

dont__panic 5y ago
Slightly unrelated, but can anybody explain why private RSS feeds are not a more popular choice for "client push" when push lag of a couple of hours isn't a big deal? The "pill reminder" app made me think about how easy it would be to host a private RSS feed for each client that the backend updates on a schedule, and clients just... check the RSS feed for an update. Maybe I'm missing something here, but it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client?
- deleted 5y ago
  [deleted]
- anon9001 5y ago
  Sure. RSS is a neat standard, but if you're writing your own app, you might as well use a custom JSON payload that's exactly what you need. If you use RSS but never actually use an RSS reader or expose it to the public, you may end up deviating from the standard, or doing extra work to be compliant with the standard that never gets used. As far as push notifications, the reality is that "push" is a bit of a marketing term. Every time your phone wakes up and gets on the network, it contacts Apple or Google and sees if there are any pending pushes to be delivered. By using the "push notification" systems, you get to piggyback on that highly optimized connection already provided by Apple or Google. These pushes have to be much smaller than your typical RSS feed and are intended for high priority delivery. An alternative, if you don't want your data going through the "push" networks, is to have your app "background fetch". You might want to do this if it's too much data (like an RSS feed would be) or if it's sensitive data (Apple and Google can obviously read all push messages). In this case, the iOS and Android have special "background fetch" use cases, which gives your app a chance to pre-load data. News apps are the canonical example. > it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client Mostly because the realtime queue already exists, it's provided mostly for free, it comes with extra features like sounds and badges, it was available before background fetches, and business people know to ask for "push" by name.
- Uehreka 5y ago
  I think it’s because most of the time a lag of a couple hours is in fact a big deal. Let’s look at some common use cases: - If I want push notifications for meetings, I want to get them exactly 10 minutes before my meeting, not 2 hours after, or 10 minutes before but +/- 30 minutes - If a customer is submitting a critical bug to my bug tracker, I want to know immediately so I can start damage control. - If a developer on my team responds to my comments on a Pull Request at 3PM, I don’t want to get the notification after I’ve clocked out at 5, causing us to essentially lose a day of work. In practice, I don’t think there are many use cases where people don’t care about the punctuality of push notifications. And if you start by tackling those use cases and then an important customer says “hey, I actually need punctuality for this new class of notifications”, then you’ll suddenly need to rebuild your whole notifications stack.
  - withinboredom 5y ago
    scrolls through notifications Yeah, I didn’t look at them at all today. I’m still alive. As a user, I don’t care about how punctual they are since I don’t look at them until the end of my work day.
    - jonny_eh 5y ago
      I didn't receive any important phone calls today, does that mean phone system reliability isn't important?
      - withinboredom 5y ago
        At least for today, for you. Phone systems go down all the time and when that happens, people DO die. No one dies because a notification gets delayed a few hours.
- mbreese 5y ago
  Because that would be a pull and not a push. Not that there is anything wrong with that, and in many use cases it would be a fine alternative. But sometimes you really do need to push data to the user even if they aren’t polling for it. Pill reminders would be something that you’d want to push. You can’t be sure the user is running your app (even in the background), and the actual state changes are rare. So some kind of mechanism where the client doesn’t initiate the check would be better. Using a long poll for email or slack or something like that can make more sense in some scenarios.
  - anon9001 5y ago
    Pedantic, but: from the device's point of view, it's always a "pull". You can't "push" to something that's not publicly addressable. From your app's point of view, you receive a "push" from the OS.
    - burnished 5y ago
      I think they are differentiating between systems that perform polling and systems that can receive interrupts (maybe not quite the right word here), I don't think that has anything to do with being publicly addressable here, in either case you sort of have to assume that devices can find each other before the difference even makes sense.
- bmicraft 5y ago
  > Maybe I'm missing something here, but it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client? Depending on the use case, you may well depend on the real-time aspect of push notifications. If my door bell rang while using headphones, I'd want to know immediately. I'd also be pretty pissed if a messenger took more than 5 seconds between sending and receiving on the other end, event if "closed" or in background.
  - dont__panic 5y ago
    Totally fair. I mostly meant this as a replacement for notification systems that aren't super time dependent. Even 5 minute pings would probably be enough for most use cases.
- sburud 5y ago
  Good point! In the mobile space, a certain walled-garden platform traditionally killed off any app 10 minutes after you left it, and even to this date does not guarantee that your app will be allowed to call home on any semi-regular basis. This makes it impossible to guarantee delivery without using the officially sanctioned push system. And if we're doing push already, why bother doing it differently on other platforms? (even if they support cross-app coordination to make the polling battery-efficient)
aadvark69 5y ago
Airship doesn't actually send the push? That's news to me
willcipriano 5y ago
Is that how it works? I would've thought it would be something like Twillo where you hit a endpoint when you want to send a message, maybe with an extra step to set up notifications on the users end in the first place. In Twillio's case after a half hour of you could end up with some sort of send_text(number, msg) function/method that you can just use all over the place and if anything changes in the text message world they handle it. Id rather do that than have to deal with the carriers, etc. The way you describe sounds like a pain with vendor lock in on top.
- Nextgrid 5y ago
  When it comes to mobile push notifications, your mobile app registers itself with the platform's (Apple or Google) push notification service and gets a token. It then has to send your server that token and your server can send pushes to it by talking to the platform's notifications endpoint and quoting that token. These third-party push notification services are essentially overlays on top of the above, don't actually change the workflow at all (the above is the bare minimum you'd need for the functionality to work) but introduce extra complexity, moving parts, and more importantly, extra rent you now need to pay to them.
  - willcipriano 5y ago
    Ahh that makes sense, thank you.
- commandlinefan 5y ago
  Twilio is actually somewhat useful. Airship is not.
gowld 5y ago
To be fair, their Pricing page tells that you aren't getting anything except buzzwords and the requirement to but more buzzwords: https://www.airship.com/app-experience-platform/pricing/ https://www.airship.com/app-experience-platform/pricing/ > AXP ENTERPRISE > Starts at $25k/Annually > 100k + MAUs > Powerful App Experiences > Mobile Data Hub > Customer Journey Optimization > Success Packages > Deep Mobile Expertise > * Overage rates apply > * Success Package required – prices may vary More charitably, I think Airship was useful before Android / iOS built their feature into the platform natively.
brimble 5y ago
I built, all on my own, a dual-platform multi-app on-demand push notification service around the same time. I can assure you, Urban Airship was not providing "absolutely nothing". If they hadn't been so expensive, we'd have used them and it would have saved me a shitload of time. Open-source support for push at the time was rudimentary (I assume that's gotten better? I haven't looked at it in about a decade) and in any case, doing it at any scale and even somewhat-good reliability involved a lot of work and dragging in tons of extra services (at least, a database and some kind of message queue service, unless you wanted to write those yourself)
- commandlinefan 5y ago
  I built one and then was forced to port it over to Urban Airship for "enterprise" reasons. I can assure you, Urban Airship is providing "absolutely nothing".
  - brimble 5y ago
    If you had certain scale assurances—a set number of apps you're sending to, never more than low-five-figures pushes in a batch, never overlapping sends at the same time, et c.—it could be a lot simpler because you could skip most of the queue management work, so sure, for some workloads and usage patterns UA probably wasn't helpful enough to be worth the money. It wasn't for us, either, but that's because we needed to charge for it and couldn't mark it up even higher than UA already did. [EDIT] Now, somewhat after that 2010 date, maybe 2012 or 2013 IIRC, UA re-structured their pricing and offering a ton which made them even less appealing to us, since their focus seemed to be value-add features for marketers on top of push, which was something we had no use for whatsoever—it's possible that by then they were indeed more trouble than they were worth if you just needed push messaging, even putting aside the cost of the service itself. If your marketing folks were big on using that as a "channel", though, it was probably very much worth it. They had a lot of features for that kind of thing.
- brimble 5y ago
  Seems wrong to edit this in, so I'll make this post for lookers-on to see what creating a reliable push messaging service looked like in the early '10s: 1) Your app needs to register with Apple to get a push token, using the app's push certificate (which you'd have to generate if your app used push messaging). It needs to send that to a server you control, because that's basically your "to" address to send messages. These were not to be treated as permanent, so to do it right you also had to be ready for these to change. Then, similar story for Android, but all shoddier, less efficient, and worse-engineered, but also higher-level—so, situation normal for Android vs. iOS in (at least) the early '10s :-) So you're looking at two similar but necessarily entirely separate implementations of this sort of functionality, to cover both platforms. 2) You need to store all those tokens your apps are sending you. 3) To send the push, you need to generate a bunch of individual messages for each address. For Apple, you'll be using the app's push cert to authenticate over a raw (I think? Memory's fuzzy) UDP connection, then blindly firing a stream of data at it (no immediate return statuses, it's a one-directional communication channel). For Google, you'll need to manually chunk these into sets of a certain max size and post the chunks one at a time to some Web endpoint. For an app with one million users sending a broadcast notification to all of them, that's one million messages each time you send. Google's system required that you implement exponential backoff, too, if you didn't want to get banned. 4) Oh, if you're sending to multiple apps, you need a way to manage (add, update) the certs (or, for Google, IIRC, an API token of some kind?) for them and to select the correct one for a given push. 5) Google would tell you at send time if an address was bad (IIRC—it has been about a decade since I touched this stuff). For Apple, you had to wait a while after a send, then open a new connection and ask for a list of bad tokens for that app, which it will happily spit at you as another UDP data stream. These will be uninstalls, folks who've turned off push for your app, whatever. You have to remove those from your token list, facing vague threats of service bans if you keep sending to bad addresses for too long. 6) If your scale is non-tiny and you need any amount of delivery guarantees or reliability, it's plain by now that you need a queue of some kind. So if you're over that line but not too far over it, you hack something together in PostgreSQL or what have you, probably make some minor but OK-for-your-needs errors in the implementation, and live with it. If your needs are greater than that, this is where you start looking at shit like AMQP, which solves a ton of your problems while giving you an ongoing maintenance headache. Retries, fanout to multiple workers, aggregating failure data, et c. There's a lot going on there. 7) Do your senders want to schedule pushes for the future? Now you get to implement cron-for-push-messages, including a UI for it. 8) Do your senders want to send individualized messages? Now you need to hook into some kind of datastore that ties those push tokens to other user data so you can fill that stuff in while generating messages. And you need at least a rudimentary templating system. 9) Do your senders want to send messages in response to user actions in the app? Now you need a way to ingest potentially very bursty and high-volume traffic from a ton of clients, and connect those to configurable push-send triggers. Probably this'll be another thing you need to route through your queuing system, if you don't want to badly over-spend on servers while not having great reliability under load. 10) Push history and stats reporting is probably gonna be needed, at some point, by someone. This list just keeps going, really.
dangerlibrary 5y ago
It's entirely possible that for your use case, Airship provided you with no value. But, just as a thought experiment: - Did you also build the audience segmentation system (and UI) for your marketing team? - Did you build a scheduled / triggered push system with per-device (or user account) rate limiting? - Did you build the streaming data interconnect to pipe audience data back to anywhere else in your organization? - Did you build the capability to remove devices that uninstalled your app from your notification list (surprisingly tricky, at least a few years ago, and APNS and Google will start getting very upset with you if you don't do this) - Did you build an embeddable notification inbox with state synced across devices? - Did you build a CDN for in-app notifications with video / images? Because Airship did, and they will sell you all of that in one package. They'll charge an arm and a leg for it, but they do a lot more than just sit as a middleman between you and APNS when sending notifications. The relatively simple backend tech is definitely not their product, and if that's all you used from them then I would understand your frustration.
ardit33 5y ago
I have build a notification sending service / gateway, and it is a pain to do. Just because Apple has no knowledge how to do proper web based apis. For small apps, that's another service to build and maintain. Airship serves well that purpose. Now, if you are a large company, and have a large volume of pushes, then it doesn't makes sense to pay Airship, but build a service yourself, and have a team to maintain it. Usually, even the smallest service, if you are doealing with Apple's (and Google's) external APi, will have trouble time to time, and you will have to have a team to 'passively' monitor and maintain it. For a company with less than 100 people, that doesn't really make sense. But with a later stage company, it totally makes sense to have your own service. Anwyay, just my 2cents, as I have done both, build my own Notification service for a startup, and used Urban Airship for my own personal projects.

dont__panic 5y ago

Slightly unrelated, but can anybody explain why private RSS feeds are not a more popular choice for "client push" when push lag of a couple of hours isn't a big deal? The "pill reminder" app made me think about how easy it would be to host a private RSS feed for each client that the backend updates on a schedule, and clients just... check the RSS feed for an update. Maybe I'm missing something here, but it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client?

deleted 5y ago
[deleted]
anon9001 5y ago
Sure. RSS is a neat standard, but if you're writing your own app, you might as well use a custom JSON payload that's exactly what you need. If you use RSS but never actually use an RSS reader or expose it to the public, you may end up deviating from the standard, or doing extra work to be compliant with the standard that never gets used. As far as push notifications, the reality is that "push" is a bit of a marketing term. Every time your phone wakes up and gets on the network, it contacts Apple or Google and sees if there are any pending pushes to be delivered. By using the "push notification" systems, you get to piggyback on that highly optimized connection already provided by Apple or Google. These pushes have to be much smaller than your typical RSS feed and are intended for high priority delivery. An alternative, if you don't want your data going through the "push" networks, is to have your app "background fetch". You might want to do this if it's too much data (like an RSS feed would be) or if it's sensitive data (Apple and Google can obviously read all push messages). In this case, the iOS and Android have special "background fetch" use cases, which gives your app a chance to pre-load data. News apps are the canonical example. > it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client Mostly because the realtime queue already exists, it's provided mostly for free, it comes with extra features like sounds and badges, it was available before background fetches, and business people know to ask for "push" by name.
Uehreka 5y ago
I think it’s because most of the time a lag of a couple hours is in fact a big deal. Let’s look at some common use cases: - If I want push notifications for meetings, I want to get them exactly 10 minutes before my meeting, not 2 hours after, or 10 minutes before but +/- 30 minutes - If a customer is submitting a critical bug to my bug tracker, I want to know immediately so I can start damage control. - If a developer on my team responds to my comments on a Pull Request at 3PM, I don’t want to get the notification after I’ve clocked out at 5, causing us to essentially lose a day of work. In practice, I don’t think there are many use cases where people don’t care about the punctuality of push notifications. And if you start by tackling those use cases and then an important customer says “hey, I actually need punctuality for this new class of notifications”, then you’ll suddenly need to rebuild your whole notifications stack.
- withinboredom 5y ago
  scrolls through notifications Yeah, I didn’t look at them at all today. I’m still alive. As a user, I don’t care about how punctual they are since I don’t look at them until the end of my work day.
  - jonny_eh 5y ago
    I didn't receive any important phone calls today, does that mean phone system reliability isn't important?
    - withinboredom 5y ago
      At least for today, for you. Phone systems go down all the time and when that happens, people DO die. No one dies because a notification gets delayed a few hours.
mbreese 5y ago
Because that would be a pull and not a push. Not that there is anything wrong with that, and in many use cases it would be a fine alternative. But sometimes you really do need to push data to the user even if they aren’t polling for it. Pill reminders would be something that you’d want to push. You can’t be sure the user is running your app (even in the background), and the actual state changes are rare. So some kind of mechanism where the client doesn’t initiate the check would be better. Using a long poll for email or slack or something like that can make more sense in some scenarios.
- anon9001 5y ago
  Pedantic, but: from the device's point of view, it's always a "pull". You can't "push" to something that's not publicly addressable. From your app's point of view, you receive a "push" from the OS.
  - burnished 5y ago
    I think they are differentiating between systems that perform polling and systems that can receive interrupts (maybe not quite the right word here), I don't think that has anything to do with being publicly addressable here, in either case you sort of have to assume that devices can find each other before the difference even makes sense.
bmicraft 5y ago
> Maybe I'm missing something here, but it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client? Depending on the use case, you may well depend on the real-time aspect of push notifications. If my door bell rang while using headphones, I'd want to know immediately. I'd also be pretty pissed if a messenger took more than 5 seconds between sending and receiving on the other end, event if "closed" or in background.
- dont__panic 5y ago
  Totally fair. I mostly meant this as a replacement for notification systems that aren't super time dependent. Even 5 minute pings would probably be enough for most use cases.
sburud 5y ago
Good point! In the mobile space, a certain walled-garden platform traditionally killed off any app 10 minutes after you left it, and even to this date does not guarantee that your app will be allowed to call home on any semi-regular basis. This makes it impossible to guarantee delivery without using the officially sanctioned push system. And if we're doing push already, why bother doing it differently on other platforms? (even if they support cross-app coordination to make the polling battery-efficient)

aadvark69 5y ago

Airship doesn't actually send the push? That's news to me

willcipriano 5y ago

Is that how it works? I would've thought it would be something like Twillo where you hit a endpoint when you want to send a message, maybe with an extra step to set up notifications on the users end in the first place. In Twillio's case after a half hour of you could end up with some sort of send_text(number, msg) function/method that you can just use all over the place and if anything changes in the text message world they handle it. Id rather do that than have to deal with the carriers, etc. The way you describe sounds like a pain with vendor lock in on top.

Nextgrid 5y ago
When it comes to mobile push notifications, your mobile app registers itself with the platform's (Apple or Google) push notification service and gets a token. It then has to send your server that token and your server can send pushes to it by talking to the platform's notifications endpoint and quoting that token. These third-party push notification services are essentially overlays on top of the above, don't actually change the workflow at all (the above is the bare minimum you'd need for the functionality to work) but introduce extra complexity, moving parts, and more importantly, extra rent you now need to pay to them.
- willcipriano 5y ago
  Ahh that makes sense, thank you.
commandlinefan 5y ago
Twilio is actually somewhat useful. Airship is not.

gowld 5y ago

To be fair, their Pricing page tells that you aren't getting anything except buzzwords and the requirement to but more buzzwords: https://www.airship.com/app-experience-platform/pricing/ https://www.airship.com/app-experience-platform/pricing/ > AXP ENTERPRISE > Starts at $25k/Annually > 100k + MAUs > Powerful App Experiences > Mobile Data Hub > Customer Journey Optimization > Success Packages > Deep Mobile Expertise > * Overage rates apply > * Success Package required – prices may vary More charitably, I think Airship was useful before Android / iOS built their feature into the platform natively.

brimble 5y ago

I built, all on my own, a dual-platform multi-app on-demand push notification service around the same time. I can assure you, Urban Airship was not providing "absolutely nothing". If they hadn't been so expensive, we'd have used them and it would have saved me a shitload of time. Open-source support for push at the time was rudimentary (I assume that's gotten better? I haven't looked at it in about a decade) and in any case, doing it at any scale and even somewhat-good reliability involved a lot of work and dragging in tons of extra services (at least, a database and some kind of message queue service, unless you wanted to write those yourself)

commandlinefan 5y ago
I built one and then was forced to port it over to Urban Airship for "enterprise" reasons. I can assure you, Urban Airship is providing "absolutely nothing".
- brimble 5y ago
  If you had certain scale assurances—a set number of apps you're sending to, never more than low-five-figures pushes in a batch, never overlapping sends at the same time, et c.—it could be a lot simpler because you could skip most of the queue management work, so sure, for some workloads and usage patterns UA probably wasn't helpful enough to be worth the money. It wasn't for us, either, but that's because we needed to charge for it and couldn't mark it up even higher than UA already did. [EDIT] Now, somewhat after that 2010 date, maybe 2012 or 2013 IIRC, UA re-structured their pricing and offering a ton which made them even less appealing to us, since their focus seemed to be value-add features for marketers on top of push, which was something we had no use for whatsoever—it's possible that by then they were indeed more trouble than they were worth if you just needed push messaging, even putting aside the cost of the service itself. If your marketing folks were big on using that as a "channel", though, it was probably very much worth it. They had a lot of features for that kind of thing.
brimble 5y ago
Seems wrong to edit this in, so I'll make this post for lookers-on to see what creating a reliable push messaging service looked like in the early '10s: 1) Your app needs to register with Apple to get a push token, using the app's push certificate (which you'd have to generate if your app used push messaging). It needs to send that to a server you control, because that's basically your "to" address to send messages. These were not to be treated as permanent, so to do it right you also had to be ready for these to change. Then, similar story for Android, but all shoddier, less efficient, and worse-engineered, but also higher-level—so, situation normal for Android vs. iOS in (at least) the early '10s :-) So you're looking at two similar but necessarily entirely separate implementations of this sort of functionality, to cover both platforms. 2) You need to store all those tokens your apps are sending you. 3) To send the push, you need to generate a bunch of individual messages for each address. For Apple, you'll be using the app's push cert to authenticate over a raw (I think? Memory's fuzzy) UDP connection, then blindly firing a stream of data at it (no immediate return statuses, it's a one-directional communication channel). For Google, you'll need to manually chunk these into sets of a certain max size and post the chunks one at a time to some Web endpoint. For an app with one million users sending a broadcast notification to all of them, that's one million messages each time you send. Google's system required that you implement exponential backoff, too, if you didn't want to get banned. 4) Oh, if you're sending to multiple apps, you need a way to manage (add, update) the certs (or, for Google, IIRC, an API token of some kind?) for them and to select the correct one for a given push. 5) Google would tell you at send time if an address was bad (IIRC—it has been about a decade since I touched this stuff). For Apple, you had to wait a while after a send, then open a new connection and ask for a list of bad tokens for that app, which it will happily spit at you as another UDP data stream. These will be uninstalls, folks who've turned off push for your app, whatever. You have to remove those from your token list, facing vague threats of service bans if you keep sending to bad addresses for too long. 6) If your scale is non-tiny and you need any amount of delivery guarantees or reliability, it's plain by now that you need a queue of some kind. So if you're over that line but not too far over it, you hack something together in PostgreSQL or what have you, probably make some minor but OK-for-your-needs errors in the implementation, and live with it. If your needs are greater than that, this is where you start looking at shit like AMQP, which solves a ton of your problems while giving you an ongoing maintenance headache. Retries, fanout to multiple workers, aggregating failure data, et c. There's a lot going on there. 7) Do your senders want to schedule pushes for the future? Now you get to implement cron-for-push-messages, including a UI for it. 8) Do your senders want to send individualized messages? Now you need to hook into some kind of datastore that ties those push tokens to other user data so you can fill that stuff in while generating messages. And you need at least a rudimentary templating system. 9) Do your senders want to send messages in response to user actions in the app? Now you need a way to ingest potentially very bursty and high-volume traffic from a ton of clients, and connect those to configurable push-send triggers. Probably this'll be another thing you need to route through your queuing system, if you don't want to badly over-spend on servers while not having great reliability under load. 10) Push history and stats reporting is probably gonna be needed, at some point, by someone. This list just keeps going, really.

dangerlibrary 5y ago

It's entirely possible that for your use case, Airship provided you with no value. But, just as a thought experiment: - Did you also build the audience segmentation system (and UI) for your marketing team? - Did you build a scheduled / triggered push system with per-device (or user account) rate limiting? - Did you build the streaming data interconnect to pipe audience data back to anywhere else in your organization? - Did you build the capability to remove devices that uninstalled your app from your notification list (surprisingly tricky, at least a few years ago, and APNS and Google will start getting very upset with you if you don't do this) - Did you build an embeddable notification inbox with state synced across devices? - Did you build a CDN for in-app notifications with video / images? Because Airship did, and they will sell you all of that in one package. They'll charge an arm and a leg for it, but they do a lot more than just sit as a middleman between you and APNS when sending notifications. The relatively simple backend tech is definitely not their product, and if that's all you used from them then I would understand your frustration.

ardit33 5y ago

I have build a notification sending service / gateway, and it is a pain to do. Just because Apple has no knowledge how to do proper web based apis. For small apps, that's another service to build and maintain. Airship serves well that purpose. Now, if you are a large company, and have a large volume of pushes, then it doesn't makes sense to pay Airship, but build a service yourself, and have a team to maintain it. Usually, even the smallest service, if you are doealing with Apple's (and Google's) external APi, will have trouble time to time, and you will have to have a team to 'passively' monitor and maintain it. For a company with less than 100 people, that doesn't really make sense. But with a later stage company, it totally makes sense to have your own service. Anwyay, just my 2cents, as I have done both, build my own Notification service for a startup, and used Urban Airship for my own personal projects.