I remember a project I worked on in the past where the requirement was to have the app display a notification to the user at a certain time, like an alarm clock. Pretty simple, and could be implemented with a line or two of code as a locally-generated notification.

But no, the lead declared that we needed a push notification from a server in order to do this properly. Even after the difference between a local notification and a push notification was explained to him (he didn't know that local notifications existed), he insisted that notifications = push notifications, and we must have a server. AND that server needed to run a complex web service. AND it needed a way for devices to log in with credentials, so it needed a database. AND it needed to be fault tolerant since this was a critical user journey in the app. AND the clients had to check in with the server periodically, since their location might have changed to a different time zone, therefore the push notification time had to change. AND this AND that AND so on. All for what was essentially an alarm clock--something you could implement in the client code running on the device in 5 minutes.

IIRC this didn't exist at the time but is indeed the ideal solution. (some more discussion of this downthread)

If pill reminders were sync'd between devices (or between mobile and web verisons of the product), then push notifications would still be necessary to inform one side or the other when to resync data if nothing else.

Still, 2010 was a wildly different time in mobile. We were all still figuring a lot out (clearly)!