With respect to releases, you don't need to release after every Sprint. The output of a Sprint in Scrum is a Potentially Shippable Product. The keyword there is "potentially". Every completed story should meet the definition of done (which should include all related tasking, such as documentation updates, unit testing, integration testing, acceptance testing, etc.). When you decide to ship your Potentially Shippable Product, this lives outside of your Scrum process and someone just goes through the submission process, probably after the Sprint Review is complete and prior to the Sprint Planning for the next Sprint.
Bugs should be treated as stories. Most bugs should simply be put onto the Product Backlog and prioritized just like any other requirement or User Story. However, you may have a high priority bug. If so, the Product Owner may opt to work with the team to decide how to fit it into the iteration. This may involve removing a User Story from the Sprint Backlog and replacing it with the story for the bug.
Tech support, if it is done by the Development Team, can be accounted for in the Sprint Planning session. When you are using your Velocity to determine how many Story Points to bring into the Sprint, adjust based on an allocation of time spent doing support work. If you have a consistent 20% of your team's time is spent on technical support every Sprint, then your Velocity would reflect this and you don't need to do any adjustment at all.