strelok011

Поделюсь своим опытом:

1. Отправлять - нормально. на сервере ты не хранишь пароль в открытом виде, а хранишь хэш. Если устройство скомпрометировано, ты никак не сможешь защититься.
2. В куке ты передаешь данные. там может храниться до 4кб разного хлама, зачем тебе это хранить на сервере? Главное что ты туда должен положить - аксесс токен, которым будет подписываться каждый запрос на авторизованные эндпойнты. Кука - просто один из механизмов для хранения и передачи этого токена с клиента на сервер. Можно точно так же отдать явным респонсом вместо куки, просто это потенциальная дыра безопасности на клиенте.
3. Токены хранишь на сервере, у них должно быть время жизни. Классика - пара часов, плюс к нему рефреш токен, которым можно перевыпустить новый. UPD Про уникальные токены - почитай например про JWT токен
4. на клиенте ты в браузере не должен ничего читать. Запрос на бэк для клиента будет типа "не подписанным", просто вместе с запросом на бэк полетит и инфа из куки, которую уже ты должен собрать и определить статус клиента.
5. Выше понятно, но тем не менее - при смене пароля просто убиваешь все ранее выпущенные токены авторизации вместе с рефреш токенами. В дальнейшем любой эндпойнт, требующий авторизации, будет возвращать какую-то ошибку, на которую фронт должен переводить пользователя в окно авторизации. Особой магии тут нет.

Надо бы насобирать еще материал, но
1. по поводу лагов - чем меньше фильтров, теней, прозрачностей - тем айфону легче. Не умеет в ускорение.
2. скролл - это отдельная БОЛЬНАЯ тема у айфонов. Причем у разных версий IOS они разные. Проблема в том, что реализация демонстрации куска верстки длинной страницы в окне браузера просто уродская. На старых айфонах, к примеру, не работал position fixed.
3. Никогда, просто НИКОГДА не пытайся прибить скользящее меню к низу страницы. Это и на андроиде выйдет дичайшим геммороем из-за автовсплывающих или автоскрывающихся панелей инструментов. Это ад и боль
4. В качестве задачи со звездочкой - попробуй реализовать модалку поверх контента, в которой свой скролл, и попробуй заблочить скролл контента в фоне. Айфон тебя порадует своими чудесами.
5. Думаю, будет весело перебирать высоту вьюпорта и подбирать позиционирование, переключаясь то на px то на wh.
6. Имей в виду - как бы не назывался браузер на айфоне - он использует одно и то же ядро сафари, специфичное для версии ios, так что глюки переносятся.
7. Ловил проблемы (тут уже не в платформе а в реализации сафари) именно в сафари если делаем display: flex, flex-direction: reverse, отваливается gap. Без реверса - всё гуд. На других реализациях таких проблем не встречал.
8. Если ты попробуешь поиграть с параллаксом самописанным - получишь ачивку "слабоумие и отвага"

Судя по постановке вопроса - в голове полная каша из обрывков знаний, уж простите :)
Рекомендую посмотреть вот этот видеоурок, хоть он и не про мессенжер, а про интернет магазин.
В видео показаны этапы проектирования продукта, планирование базы данных, реализация, создание эндпойнтов, разработка фронт-приложения.
Если вдумчиво смотреть и сразу применять, разбираться почему и зачем, и как это можно будет расширить и изменить под себя, вы точно сможете сделать что-то свое.
Если не хватит базы знаний - копайте статьи в интернете по тому инструменту или области, которая для вас темный лес.
Вот тут в "двух словах" рассказано как сделать проект.

1. проприетарные почтовые клиенты не используют веб движки в своей массе, так что там поддержки модных фич не стоит и пытаться ожидать.
2. имейте в виду что любой почтовый клиент (хоть онлайн, хоть стационарный) переиначит ваш html код своими встроенными парсерами в то, на что рассчитано его окно вывода сообщения.
3. для упрощения верстки писем попробуйте воспользоваться mjml, легко гуглится и результат вполне себе.

Чтобы не кропало - релативный блок должен находиться за пределами оверфлоу.

Решение - дропдаун класть в тело документа за пределами родительского блока, писать муторную обвязку на js с вычислением координат порождающего элемента на экране, по ид вычислять что класть в этот пустой дропдаун, либо искать такой дропдаун в готовых библиотеках, лет 5 назад натыкался на такое готовое.
Либо примерно ту же муть с вычислением позиционирования но с оберткой вокруг вашего блока с оверфлоу и без выноса дропдауна.

<div style="position:relative">
    <div style="width:280px; height: 100px; border:1px solid red; overflow:hidden; ">
        <ul>
            <li style="/* removed position:relative; */ width:200px; height:50px; list-style-type:none; background:yellow;z-index: 3;">
                <div style="position: absolute; top: 30px; left: 52px; width:180px; height:150px; background:Pink; z-index: 99;">
                    <br>
                </div>
            </li>
        </ul>
    </div>
</div>

Ну, еще вариант конечно, если вы точно знаете смещение порождающего элемента - писать позиционирование в стилях жестко прибитое, но это уже моветон и вообще не гибко.

Такое бывает в ситуации, когда в контенте или в любом блоке присутствует элемент или контейнер шире, чем ширина страницы. Это могут быть как изображения, так и элементы у которых неправильно заданы параметры с шириной и паддингом.
Т.е. если есть элемент с шириной 100% и паддингом, ему надо бы указывать box-sizing: border-box;
Так же могут влиять неверно применяемые флоаты, флекс и прочее.
Первый шаг для проверки - накидывать overflow: hidden на контейнеры чтоб локализовать проблему, где именно находится распирающий элемент, либо в отладчике включить инструмент выбора элемента на странице и искать в пустой казалось бы области.