Da das Thema heute auch auf Twitter an mich herangetragen wurde, beantworte ich das auch mal hier.
Das Problem ist nicht wirklich beim Button zu suchen. Um auf dem Gerät die richtige App zu triggern, wird das Schema der URL genutzt.
Um z.B. die App von Apple auf dem iPhone aufzurufen, wird aus
http://fasel.bla
podcast://fasel.bla
Durch das Schema “podcast://”, das die App in iOS registriert hat, weiß das Gerät, welche App aufgerufen werden soll.
Und genau hier steckt dann das Problem. Durch das ersetzen des Schemas ist für die App hinterher nicht mehr identifizerbar, ob es sich um http oder https handelt. Als das alles erdacht wurde, war https kein wirkliches Thema und deshalb wird an der Stelle immer http unterstellt.
Dafür gäbe es nun zwei Lösungen: Die Apps reagieren und registrieren zwei Schemata (ob das geht, weiß ich nicht, dafür steck ich nicht genug in der Programmierung unter iOS, Android + Co). Eine könnte dann podcast:// heißen, eine ander podcasts:// - eine Unterscheidung wäre wieder möglich.
Eine andere Lösung liegt beim Podcast bzw. dem Hoster: Eine permanente Weiterleitung von http:// auf https://
Beide Lösungen finde ich irgendwie nicht richtig prickelnd. Über zwei Schemata bin ich zwar erstmal raus aus der Nummer, aber erstens ist es unwahrscheinlich, dass alle Apps hier anständig reagieren und das zeitnah erledigen und nunja… wenn irgendwann ein drittes Schema auftaucht (was weiß ich, was dieses Web für uns noch so bereit hält) oder jemand auf die Idee käme, ganz andere Protokolle heranzuziehen (ftp://? ;-)), dann sieht’s düster aus. So richtig sauber ist das alles nicht.
Lösung zwei birgt das Problem, dass man vom Hoster abhängig ist und nicht alle können das am Ende umsetzen.
Dennoch würde ich, weil kurzfristig umsetzbar, aktuell immer Lösung zwei vorziehen. Am Ende bleibt das der realistischste Weg. Eine kleine Konfiguration am Webserver und gut.
Hab ich was vergessen? Bestimmt 
